Work around deadlock when destroying J2KEncoder with a full writer queue (#2784).v2.16.83

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.

1 files changed, 10 insertions, 0 deletions

diff --git a/src/lib/j2k_encoder.cc b/src/lib/j2k_encoder.cc
index 7c9777c16..32d2fefc2 100644
--- a/src/lib/j2k_encoder.cc
+++ b/src/lib/j2k_encoder.cc
@@ -69,6 +69,16 @@ J2KEncoder::~J2KEncoder ()
 {
 	_server_found_connection.disconnect();
 
+	/* One of our encoder threads may be waiting on Writer::write() to return, if that method
+	 * is blocked with the writer queue full waiting for _full_condition.  In that case, the
+	 * attempt to terminate the encoder threads below (in terminate_threads()) will fail because
+	 * the encoder thread waiting for ::write() will have interruption disabled.
+	 *
+	 * To work around that, make the writer into a zombie to unblock any pending write()s and
+	 * not block on any future ones.
+	 */
+	_writer.zombify();
+
 	boost::mutex::scoped_lock lm (_threads_mutex);
 	terminate_threads ();
 }