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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
