Branden wrote:
Actually, with event loops and threading issues, probably things like
the perl built-ins sleep and alarm won't ever be passed to the syscalls
sleep(3) and alarm(3).
Sleep isn't usually a syscall -- it's often a library routine that sets
an alarm and blocks or uses some other general purpose syscall to block.
Perl *must* use one of these OS features unless you want to busy wait.
Perl will probably block that instance of the
interpreter internally and do some other stuff. It will probably use
its internal clock to measure the time to unblock it, and that clock
will probably have sub-second precision.
That's silly. You want perl to block a thread and then busy wait until
it's time for the thread to wake up? Even if perl has other threads
going it will be incredible wasteful to check a timer between every OP.
Lots of discussion on signal delivery has taken place and it seems like
people have agreed to have async delivery with the signal handler called
at the next "safe" opportunity -- between expression boundaries for
example. IMHO making alarm a high-resolution timer is not consistent
with safe signal delivery. If a user asks for alarm(10) and gets a signal
12 seconds later that's probably ok. If a user asks for alarm(0.005) and
gets a signal 1 second later that's a problem. (Perl isn't Java -- we
have lots of OPs that can take a long time to run.)
Basically I'm afraid of advertising high-res timers and then having
so many caveats that they aren't useful or portable. Stuff in the core
should be dependable.
- Ken
P.S. I didn't realize anybody was doing video games or device drivers
in Perl. Has anybody ever written code where the resolution of alarm was
a problem? I've only used alarm to prevent blocked I/O from hanging
servers. For graphical programs I've always used the toolkit dependent
alarm features.
