[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: 1-millisecond sleeps
From: |
Udo Giacomozzi |
Subject: |
Re: [Gnash-dev] Re: 1-millisecond sleeps |
Date: |
Wed, 11 Jul 2007 10:24:28 +0200 |
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