On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote: : On Mon, 23 Feb 2009, Timothy S. Nelson wrote: : > I have a quick question here. S16 claims to be about IPC, IO, and : > Signals. So far, it's mostly about IO. My question is, is it intended : > that IPC and/or signals be part of the core, or should they be converted : > to addons like Form.pm? : : 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. 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. : That's not to say that methods for setting the signal handler needs to be in : the core though, just the low-level code that receives signals and arranges : not to leave a (broken) partially-formed call frame in the chain while : setting up a call frame to invoke the handler function. The low-level signals should almost immediately be turned into events and queued to the low-level event handler. The user can then choose to include these events in any higher event handler, or leave the default signal event handler to translate the event to an exception, hopefully not in a random thread that isn't expecting it. Note that feeds and lazy lists map rather nicely to event streams, so all we really need is a way of tapping into the low-level event mediator to tell it which events we're interested in intercepting. I suppose we could go so far as to say that the default is that all unclaimed events turn into resumable exceptions by default, and are simply discarded if no handlers exist in the dynamic scope. Larry
