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

[Michael Niedermayer]

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.

What you suggest might be correcter in an ideal world and iam all in favor
of it if it is simple and can and _IS_ done. But i definitly dont want
a perfectly working and simple solution to be rejected because you
consider it not "correct" while no other solution is ever implemented or
is so insanely complex that people just ditch it and call yield.

What you suggest needs a select() like system that works with files,
network protocols, audio and video grab APIs as well as screen capture
APIs needs to work on all platforms
that support yield()/sleep() of some kind and needs to work with
any set of supported protocols on that platform and needs protocols
to pass thier file/object handle(s) through demuxers to the user app so
it can do that select() call

Is someone planning to implement this?

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/eb981e19/attachment.pgp>