From 32d04ddb5c583938f470ed74bda8a50cc2ec9960 Mon Sep 17 00:00:00 2001 From: Carl Hetherington Date: Sun, 5 May 2024 21:34:29 +0200 Subject: Work around deadlock when destroying J2KEncoder with a full writer queue (#2784). This feels like a hack, but I can't think of a nicer way to do it. The interruption disable makes sense because when we destroy encoder threads during a DCP encode (because a remote server goes away, for example) we don't want any frames to be lost due to the encode thread being interrupted between taking the frame off the queue and sending it to the writer. When we're destroying the encoder we don't care about this, but I can't see how you'd differentiate. Maybe the encoder queue could have two lists: to-do and in-progress; the encoder thread atomically moves a frame from to-do to in-progress, but then how do you know when the in-progress ones are orphaned and need to be re-added to the main queue. You could make the writer return saying "no" if the queue is full (rather than blocking and waiting for the queue to empty) but that seems wasteful as then the frame would be re-encoded. --- test/wscript | 1 + 1 file changed, 1 insertion(+) (limited to 'test/wscript') diff --git a/test/wscript b/test/wscript index bb66d1a5f..cd23badc0 100644 --- a/test/wscript +++ b/test/wscript @@ -112,6 +112,7 @@ def build(bld): interrupt_encoder_test.cc isdcf_name_test.cc j2k_bandwidth_test.cc + j2k_encoder_test.cc job_manager_test.cc kdm_cli_test.cc kdm_naming_test.cc -- cgit v1.2.3