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.
