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.

Backported from df48c75c38dd788835a93540aea243a2dac4bb10 in v2.15.x

0 files changed, 0 insertions, 0 deletions