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

[Michael Niedermayer]

On Tue, Mar 03, 2009 at 06:52:47PM +0100, Luca Abeni wrote:
> Michael Niedermayer wrote:
> [...]
> >>>> AFAIK, sched_yield() on non real-time task is not a good idea (it has an
> >>>> undefined behaviour).
> >>> which page of POSIX says that?, i cant find it ...
> >> I think POSIX defines the sched_yield() behaviour only for SCHED_FIFO and
> >> SCHED_RR (basically, a task is moved at the end of its priority's queue).
> >>
> >> opengroup.org says:
> >> The sched_yield() function shall force the running thread to relinquish the processor until it again becomes the head of its thread list. It takes no arguments:
> >> http://www.opengroup.org/onlinepubs/000095399/
> >>
> >> The problem is that (AFAIK) the concept of "head of its thread list" only
> >> makes sense for fifo and rr.
> > 
> > are you saying that sched_yield() will blow up and cause actual undefined
> > behaviour and that we should use usleep(0) or what else?
> 
> Well, I think sched_yield() will deschedule ffmpeg for a random amount 
> of time, which can change from kernel version to kernel version (it 
> already happened in the past, when cfs was introduced). This is probably 
> ok (as I said, I do not object to this patch), but maybe in some 
> situations it might happen that ffmpeg "sleeps" for too much time 
> causing overruns or something similar... I do not know. Let's commit the 
> patch and see what happens.
> 

> I was not suggesting usleep(0) (which, of course, is not better than 
> sched_yield()): I was just wondering if we might be able to predict when 
> the next frame will be available, and to usleep() for the right amount 
> of time... Anyway, this can be committed in a second time (if worth), 
> after your patch is committed.

what my oppinion is, is that its not the user applications job to guess
this, thats also why i considerd sched_yield() more correct than
usleep(something).
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.


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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/e8f0757e/attachment.pgp>