[vlc-devel] [PATCH 3/8] picture_pool: use the internal condition/lock indirectly
remi at remlab.net
Mon Jul 27 20:51:28 CEST 2020
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
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.
More information about the vlc-devel