[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).

Michael Niedermayer michaelni
Fri Mar 5 04:18:55 CET 2010


On Fri, Mar 05, 2010 at 02:58:57AM +0000, M?ns Rullg?rd wrote:
> 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.

but it should solve the problem
the cputime is made available to other processes. If its 100% when there
are no other processes is irrelevant.
Also usleep() could be tried when sched_yield() doesnt do what we want it
to.
Again to clarify my point, i understand and agree that select() is the proper
way but i fear it wont ever be implemented or if it is will be a quite complex
mess. a simple usleep/nanosleep/sched_yield/whatever is quite appealing to me
due to its simplicity and i dont see any real world advantage for us in select
anyway but then i did not compare them in actual implementation ...

and id gladly be proofen wrong with a simple select() based [PATCH]

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

It is not what we do, but why we do it that matters.
-------------- 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/20100305/07c893f6/attachment.pgp>



More information about the ffmpeg-devel mailing list