On Fri, 27 Feb 2009, Martin D Kealey wrote:
On Thu, 26 Feb 2009, pugs-comm...@feather.perl6.nl wrote:
+The exceptions are:
+
+ Signal Action R Comment
+ ----------------------------------------------------------------------
+ ControlExceptionSigHUP Term ? Hangup detected on controlling terminal
or death of controlling process
[...]
+ ControlExceptionSigCHLD Ign ? Child stopped or terminated
[...]
+ ControlExceptionSigURG Ign ? Urgent condition on socket (4.2BSD)
[...]
+ ControlExceptionSigWINCH Ign ? Window resize signal (4.3BSD, Sun)
[...]
+XXX I'm unsure how the actions in the table above can be made to make sense.
The Ign
+actions are already dealt with because %SIG{CHLD}.exception already defaults
to undef.
+The Term action will probably be self-solving (ie. will terminate the
process). The
+others I'm just plain unsure about. XXX
That looks a lot like a mangled version of "man 7 signal" from Linux.
IMHO the default action shouldn't be specified at all by the Perl standard;
it should simply refer to the appropriate external standard.
It is a mangled signal(7), but the reason it's there is that I want it
to become more Perl-specific. In particular, I want to have the R field
filled in, so that I know which are to be resumeable.
Also, as my understanding of the plan is that the low-level signal
handling in perl6 will capture the signal, throw the exception, and then
continue or something (cf. Larry's earlier message if what I just said doesn't
make sense), then presumably we want to make the signal-caused exceptions do
the same thing as they would've done if we hadn't handled them.
Of course, I could be all confused again :).
Also, by documenting this system of defaults, it will hopefully act as
a beginning for user documentation :).
In POSIX the settings "terminate", "ignore", "catch" and "default" have
3½ distinct meanings. For *most* signals "default" is the same as
"terminate" (sometimes with a core), but not for all.
Ok, I see that now. Probably the Action column should go, then, but
I'd like to keep it until we figure out how to simulate the other actions in
our signal/exception-handling code.
In particular, for SIGCHLD, if you "ignore" it, the "wait" call will
always fail (having delayed until all child processes have exited),
whereas if you leave it as "default", your process will still ignore it,
but "wait" will work properly.
Ok, I'll tell that one to throw the proper exception. We'll probably
have to make it resumeable, and have PROCESS catch it if we can, unless a
CONTROL block (ie. inside a wait()) gets it first.
On some implementations SIGUSR1 and/or SIGUSR2 are ignored by default.
Well, we're overriding everything we can, handling them, and creating
exceptions.
Core dumps are subject to ulimit controls, even when the signal in question
would normally trigger them.
Good point :). That'll be hard to simulate.
Btw, I'm glad to have someone here who understands signals better than
I do :).
---------------------------------------------------------------------
| 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-----
