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

Reply via email to