[FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Wed, Dec 02, 2015 at 03:13:33PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > because concurrent read/write accesses on the fifo needs to be locked?
> 
> No, of course not.

I was talking about the fifo itself, not the threadmessage API.

> 
> > I don't understand...
> 
> *I* do not understand what you need, what you want to do with this API. To
> discard all elements, just read them until there are no more, no need of
> locking (except internally to read them, of course), no need for anything
> else. So what am I missing?

I'd say it prevents the sender (application side) to become a reader in
order to read every message concurrently with the dedicated reader(s) in
the goal of discarding them so they can't read them.

In case I'm not clear, one simple scenario would be the following:

 - there is a large queue of packets, almost filled
 - there is one fast sender filling the queue (the demuxer)
 - there is a bunch of slow readers reading from the queue (the decoders)
 - the sender "receives" a seek event from the user
 - the sender now wants to stop as fast as possible readers (decoders)
   from reading all kind of packets

If that sender has to lock for every message it's going to read & drop,
while the decoders are still fighting to read them from the queue, it
looks very ineffective to me.

Hopefully this clarifies. I'm not sure what kind of similar information I
could write in the doxy. If you have any suggestion...

I will send a new patchset very soon (with important bug fixes and
improvements)

Regards,

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151202/d19e2ade/attachment.sig>