Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_final-1963-g63de409

[John Gilmore]

> In my experience, select() is to be preferred over poll() in that it
> doesn't hog the processor in the same way.  select() uses an
> asynchronous I/O implementation which allows the process to yield
> until the specified activity occurs on the file descriptor or the
> timeout expires while poll() checks the file descriptor for the
> specified activity over and over again until the timeout expires or
> the activity occurs.

Gnash does have a problem with hogging the processor but it isn't
poll()'s fault.  Just like select, poll suspends the process and lets
other processes run until the condition happens.  I think they have the
same kernel implementation once you get past the system call interface.

Both can burn a lot of CPU if the timeout is short.  They're designed
to work best when no timeout is needed, or perhaps the process does
quick timeouts while data is flowing regularly, then notices it's out
of work, does cleanup, and sets its timeout much longer (half a minute
or half an hour, perhaps).  Of course it immediately starts executing
as soon as any data flows, and can decide how long a timeout to ask for
the next time around the loop.

Gnash's problem in this area is that script code is defined to be
called every frame time, and other graphical actions occur then.  Gnash
doesn't know how to detect innocuous no-op every-frame code that
doesn't really need to execute every 60th of a second.  So it does a
lot of short poll()s and select()s and accumulates a lot of useless
CPU time doing nothing many times a second.

        John