Fix deadlock during content examination.

Before this fix, the following situation could happen in threads
A and B:

A: Some DONE signal happens; this triggers setup_pieces which
   takes a lock on the player mutex.

B: FFmpegContent::examine takes a lock on the content mutex.
B: FFmpegContent::examine adds a stream
B: That causes STREAMS PENDING to be emitted.
B: This tries to take a lock on the player mutex so it can update _suspended

A: setup_pieces tries to access some content information, hence
   tries to take a lock on the content mutex.

Now B is holding the CL and awaiting the PL and A is holding
the PL and awaiting the CL.

It feels like the root cause of this is that while setup_pieces
is happening another change (which would itself cause setup_pieces)
is announced, and this isn't dealt with properly.

There are two steps here; _suspended is protected with an atomic
rather than using _mutex, and also it can cope with being updated
recursively.

1 files changed, 2 insertions, 2 deletions

diff --git a/src/lib/player.h b/src/lib/player.h
index 2fd7c8668..68531cfb3 100644
--- a/src/lib/player.h
+++ b/src/lib/player.h
@@ -149,8 +149,8 @@ private:
 	boost::shared_ptr<const Film> _film;
 	boost::shared_ptr<const Playlist> _playlist;
 
-	/** true if we are suspended (i.e. pass() and seek() do nothing) */
-	bool _suspended;
+	/** > 0 if we are suspended (i.e. pass() and seek() do nothing) */
+	boost::atomic<int> _suspended;
 	std::list<boost::shared_ptr<Piece> > _pieces;
 
 	/** Size of the image in the DCP (e.g. 1990x1080 for flat) */