Em Seg, 2009-02-23 às 19:49 -0800, Larry Wall escreveu: > On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote: > : Conceptually I think they should all go in add-on(s), however I suspect that > : when an exception is thrown inside a signal handler, cleanly unwinding the > : call chain will need special support in the core. > Which should already be there, presumably, as defined in S04 and such. > Some signals like CONT want to get translated to resumable exceptions > and others like SEGV to non-resumable.
Agreed, every signal could just be a control exception with no special behavior (except being potentially resumable), simply: * ControlExceptionSigHUP * ControlExceptionSigTERM * ControlExceptionSigINT * and so on... Then defining a signal handler is just a matter of a CONTROL block that catches that exception. This would mean something that is very important in terms of concurrency, which is that the signal handling code that is registered in the OS is simply there to raise the exception, once that happens, the regular execution flows to the CONTROL block. We would just need to decide if a signal should be seen by all of the concurrent threads (green-threads or os-threads), or if there is a "main" thread that would receive the exceptions or how the user can tweak that behavior... Then the outermost dynamic scope would define a CONTROL that would implement the default behavior for each control exception (as it already does for ControlExceptionWarn, for instance. > These signal events will > presumably be processed by some kind of underlying event handler that > mediates among any and all user-visible event handlers within the > process. Now *that* made my eyes shine. ;) Adding a library-agnostic event loop at the core is something that might be very much powerfull. The AnyEvent p5 modules is one of the most interesting things in this regard in CPAN, it works with any event loop (including POE, Event and EV). So the default code that raises the control exception for each signal would be registered in this event loop, as well as any code that wanted to perform asynchronous IO, which would just register a listener for "can_read" in soe IO handle. We just need to sketch an API around that... daniel
