Re: Signals question for S16: IPC / IO / Signals
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
Re: Signals question for S16: IPC / IO / Signals
On Tue, 24 Feb 2009, Daniel Ruoso wrote: 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. ;) I'm in favour of discussing this idea too (I like it myself :) ). 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... I've never heard of AnyEvent before now, but after a quick skim over, I'd say the AnyEvent API looks good. Any opinions on that? - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Signals question for S16: IPC / IO / Signals
On Tue, 24 Feb 2009, Daniel Ruoso wrote: 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... Well, now that we seem(?) to have eliminated the need for %*SIG, could we use that for defining which thread gets the signals? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Signals question for S16: IPC / IO / Signals
I think most forms of IPC should be addons, if only because they have inherent unportability. Stuff like sockets and pipes should be in obviously, signals maybe (they have lots of portability issues, but they may be too often used to just drop), but things like SysV IPC really shouldn't. Anything more high level should definitely not go in the core. Leon (my apologies to Timothy, who now gets this twice, I screwed up due to gmail having issues with this mailing list). On Mon, Feb 23, 2009 at 2:26 AM, Timothy S. Nelson wayl...@wayland.id.au 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? Thanks, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Signals question for S16: IPC / IO / Signals
On Tue, Feb 24, 2009 at 1:13 AM, Timothy S. Nelson wayl...@wayland.id.au wrote: On Mon, 23 Feb 2009, Leon Timmermans wrote: I think most forms of IPC should be addons, if only because they have inherent unportability. Stuff like sockets and pipes should be in obviously, signals maybe (they have lots of portability issues, but they may be too often used to just drop), but things like SysV IPC really shouldn't. Anything more high level should definitely not go in the core. Ok, I agree about the SysV IPC. Files and Sockets are in. As for the rest, I have another question -- should they be part of a Unix-only class? I don't understand your question; what do you mean with 'they' here? Anything not in the core doesn't have to be specced at all for now.
Re: Signals question for S16: IPC / IO / Signals
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. 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. -Martin
Re: Signals question for S16: IPC / IO / Signals
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
