Re[2]: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp

[Udo Giacomozzi]

Hello Martin,

Friday, July 6, 2007, 12:13:45 PM, you wrote:
MG>   In general I agree that tu_* should be dropped wherever possible,

What's the problem with tu_timer? I interpreted it as a general Gnash
tool for timing. Anyway, wouldn't it be best to have a dedicated .h
just for timing purposes?

MG>    In general this NullGui code "could be improved".
MG> - Infinite loops peppered with breaks are confusing. I know Gnash is
MG> full of them, but they are error-prone and a sign of confused
MG> thinking. It would be better to figure out what the loop terminates
MG> on, then loop for that explicitly.

The infinite loop design was taken to avoid calls to usleep() when the
delay is 1. This will probably be the most used value when one uses
the "-d" switch. This allows much better performance profiling because
any call to usleep() will slow down Gnash dramatically.


MG> - A busy-wait with usleep(1) (currently making a call up to 1000000
MG> times a second to very slow localtime code!)

Not correct. usleep(1) does not really sleep a nanosecond. It just
causes a task switch which on most architectures corresponds to a 10
milliseconds sleep (100 HZ). With other words, the usleep() call is
just to release CPU resources to other processes and it does not
matter what value was given to usleep and how fast the code is between
the sleeps.

MG> would be best replaced by
MG> working out how long to delay for in absolute time and then calling
MG> usleep with the right amount.

usleep() just sleeps _at least_ the specified time (unless interrupted
by a signal), which means the timing would be inaccurate in that case.


MG> Anyway, in windows here we have #define
MG> usleep(n) Sleep(n/1000) so that has a true 100% CPU busy loop.

You mean because that equals  sleep(0) ?

On http://msdn2.microsoft.com/en-us/library/ms686298.aspx they say:

"A value of zero causes the thread to relinquish the remainder of its
time slice to any other thread of equal priority that is ready to run.
If there are no other threads of equal priority ready to run, the
function returns immediately, and the thread continues execution."

This sounds like 0% CPU to me. However I admit that I don't really
thought about Windows when patching NullGui.

Udo