[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).
Måns Rullgård
mans
Fri Mar 5 03:58:57 CET 2010
Michael Niedermayer <michaelni at gmx.at> writes:
> On Fri, Mar 05, 2010 at 02:22:18AM +0000, M?ns Rullg?rd wrote:
>> Ramiro Polla <ramiro.polla at gmail.com> writes:
>>
>> > Hi,
>> >
>> > Currently FFmpeg eats 100% cpu on devices that return EAGAIN. Attached
>> > patch makes FFmpeg yield when it gets EAGAIN. In Windows it gets down
>> > to normal cpu levels, but on Linux this didn't work as I expected, it
>> > still eats 100% cpu. Any ideas?
>>
>> It's the wrong approach. The spec for sched_yield says:
>>
>> The sched_yield() function shall force the running thread to
>> relinquish the processor until it again becomes the head of its
>> thread list.
>>
>> On some kernels this puts the thread out of action for a full tick,
>> which is probably what you are seeing on Windows (yes, it has a
>> different name there). On a modern Linux system it will merely invoke
>> the scheduler, which will notice that nothing else wants to run and
>> put this thread back on the CPU immediately. Check with "vmstat 1" if
>> system the call rate shoots up while running this.
>>
>> The correct solution is to make the devices somehow notify when input
>> is available so the process can sleep properly while waiting. On Unix
>> systems this is typically done with select() on a file descriptor. On
>> Windows something like WaitForMultiPleObJectS() is used. Perhaps that
>> is something we could create an abstraction for.
>
> The question is not only what is the philosophically correct approach but
> also how complex and portable it is.
> And yield() is quite portable and as you see from this patch quite simple.
Simple is irrelevant when it fails to solve the problem.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list