Dan Sugalski <[EMAIL PROTECTED]> writes:
>Using alarm and $SIG{ALRM} to abort blocked or long-running things is one
>of the biggies (personally I think I'd prefer some sort of eval block with
>a timeout attached), since it doesn't work threaded, doesn't work well
>outside of Unix/VMS (read: WinXX),
I works "better" on Win32 than it does on UNIX - provided you have something
(e.g. Tk) which is harvesting Windows messages - it is all nicely synchronous.
>and won't let you have multiple one-shot
>or periodic timers. Using a signal, in this case, is something of a hack
>(though not ours) that can be done better.
>
>I/O events are another area where we'll want to hide signals generally,
>since the PerlIO layer will want to be taking care of that itself.
I have some sympathy with Uri's position here. Signals and event loops are
close cousins. What I am less clear about is whether we want to go down
the Tcl route, or do something even more radical like making op despatch
and the event loop _the same thing_. (If we think of perl's ops as the
instructions of our virtual machine, then this is like what happens when
a hardware processor is "interrupted".)
--
Nick Ing-Simmons