Re: [Gnash-dev] Re: 1-millisecond sleeps

[Udo Giacomozzi]

Hello John,

Tuesday, July 10, 2007, 10:51:56 AM, you wrote:
JG> Usleep(1000) is a terrible way to allow a task switch. The Linux
JG> kernel will do a task switch whenever it's appropriate. The
JG> buzzword is "fully preemptible". It's not like a 1980's Macintosh,
JG> where applications had to explicitly task switch or the kernel
JG> would never regain control. You don't need to tell Unix or Linux;
JG> it's automatic.

If all programmers would think like this then "top" would show
continously show 100% CPU usage, your CPU fan would run like crazy and
the energy consumed by computers would be even higher - not to mention
that programs on your desktop would respond slowly.

Giving the scheduler a *hint* that he can do a task switch is *not*
the same as the 16-bit multitasking (Win 3.1) where a program *had to*
pass over control to other processes.


JG> So what are you *really* trying to do here?  Is there some other task
JG> that you want the kernel to run?  If so, send it a message; write a byte
JG> to a socket or FIFO that that task is listening on; etc.

Yes, I want the kernel to run other tasks: any task that wants to.
This is kinda silly discussion, I don't get what's your problem with
usleep(). You always need usleep(), select() or similar functions
unless your CPU has to handle only one single process.


JG> What you *do* need to tell the Linux kernel when you sleep is "when is
JG> the next time my current task will have some useful work to do?".  You
JG> tell it that by the duration of your sleep request.  If you don't know
JG> when there'll be more work to do, then don't sleep at all.  Instead,
JG> do a system call like read() or select() or poll(), which will put you
JG> to sleep until something interesting happens on one of your file
JG> descriptors.

I have no FDs I need to read/write!? I just need to wait a specific
time. That's what usleep() is meant to, after all.

Yes, I could usleep() the /exact/ remainder time instead of using a
loop, but the current design /probably/ offers a better precision.


JG> The whole Linux community is going around cleaning up old code that
JG> does things like wake up 1000 times a second for no reason.  Besides
JG> the inefficiency and ugliness of that approach, it also burns power
JG> for no reason.

usleep() code burns power? Huh? You burn power if you don't use it.

Maybe you're talking about using select() or a signal-based design
instead of polling. Yes, that's much more efficient and I use it every
day, but you can't use it in this specific case!


JG> Many CPUs will slow their clocks and save power when
JG> lightly loaded.  The OLPC will actually power off its CPU chip if it
JG> knows you'll be sleeping for at least a few seconds.

Yes, sure, but no movie has a inter-frame time of some seconds. We're
talking about something like 3 calls to usleep(). No CPU will power
off in such a short time. The CPU will save power, yes, but it will do
so equally no matter if there's one or five calls to usleep().

This is a movie player, not a forever-running data acquisition
software that uses some CPU cycles every few minutes.

Furthermore, we are talking about a portion of Gnash that will
probably never be used by any normal Gnash user!


JG> It can't do that for a thousandth of a second -- and it has no way
JG> to know that your code will go right back to sleep when awakened.

It's a matter of precision vs. power consumption.

Anyway, I stil think the code is fine for it's purpose. It's probably
0.000001% of the total time that Gnash keeps busy the CPU.


If you still don't like the design, then change it. I use NullGui only
for profiling, not wanting any usleep() call at all. Period.


Udo