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

[Luca Abeni]

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.


> 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 :)


				Luca