[FFmpeg-devel] [PATCH] What is missing for working AVFMT_FLAG_NONBLOCK?

[Michael Niedermayer]

On Tue, Mar 03, 2009 at 07:50:13PM +0100, Nicolas George wrote:
> Le tridi 13 vent?se, an CCXVII, Michael Niedermayer a ?crit?:
> > The kernel knows excatly what we polled in the last timeslice when we
> > called sched_yield() it could (in theory) just give us the cpu again
> > if one of the polled things became available.
> > IMHO this would be alot nicer for (some) applications than having to
> > explicitly collect things (where its possible at all) and run select()
> > and then deal with all the special case about signals.
> 
> That would be nice indeed, but that is not possible with current Unix APIs,
> and that is definitely not what sched_yield does.
> 
> The nearest to what you describe would be signal-driven IO: enabling O_ASYNC
> on the file descriptors and then using pause() to wait for a SIGIO.
> 
> Unfortunately this is not portable: this is BSD and never made it into POSIX
> or Single Unix; furthermore, it is made for sockets, there is no guarantee
> that it would be implemented for devices.
> 

> I really think that the only reliable and portable way to deal with blocking
> inputs is threads.

yes
but not all are blocking and even with threads my patch still is needed,
because ffmpeg currently will try to pull data from one input until it
gets something from that one, if now for whatever reason this does not
happen the buffers (threads or not) of the others will overflow.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090303/2d183e8f/attachment.pgp>