[vlc-devel] [PATCH 3/8] picture_pool: use the internal condition/lock indirectly

[Rémi Denis-Courmont]

Le maanantaina 27. heinäkuuta 2020, 20.40.49 EEST Steve Lhomme a écrit :
> I don't think I said there's no deadlock anymore.

You removed the code that prevented that class of deadlock. And I specifically 
asked if that simplification wouldn't expose the decoder to deadlocks...

> In pull model it was easy. The pool belonged to the vout so it was not
> tied to such lock. It was possible to cancel the pool regardless of who
> is waiting. Now that pools are in many decoders (and in many forms) it
> becomes tricky to do this. But we need a solution anyway.

You can't expect to be able to pass a "cancellable" to each and every place 
that might sleep. Experience has shown that this just doesn't work.

If a module has a private object upon which it sleeps, it is responsible for 
not locking itself up. For instance, access and access_demux modules are 
responsible for stopping any asynchronous or threaded activities as needed. A 
contrario, stream filter and demuxer modules rely on the interrupt framework - 
because the sleeping happens within the underlying stream that is given to 
them.

If a decoder is waiting on a pool through the decoder owner from the video 
output, it makes sense, or at least it's hardly avoidable, that the decoder 
owner and the video output are partly responsible for unblocking. But if it's 
a private pool of the decoder, it is the decoder's responsibility to do the 
needful upon flush or destroy.

-- 
レミ・デニ-クールモン
http://www.remlab.net/