[FFmpeg-devel] [PATCH] What is missing for working AVFMT_FLAG_NONBLOCK?
Tue Mar 3 18:52:47 CET 2009
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:
>> 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.
> I really feel that sched_yield() is correct and usleep() is not.
> thats IMHO from reading POSIX and the man pages
My understanding (which might be wrong) is that the POSIX standard is
not well defined for the SCHED_OTHER case. I have already seen some
"interesting discussions" about this :)
More information about the ffmpeg-devel