Fix deadlock during content examination.
authorCarl Hetherington <cth@carlh.net>
Tue, 28 Jan 2020 22:23:47 +0000 (23:23 +0100)
committerCarl Hetherington <cth@carlh.net>
Tue, 28 Jan 2020 22:23:47 +0000 (23:23 +0100)
commitdf48c75c38dd788835a93540aea243a2dac4bb10
treeddb89cf5bada00cfe4e77301c71123297bd24946
parent95f4d8740de74cdecf6658ab2607c0af9732904e
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.
src/lib/player.cc
src/lib/player.h