[.courtesy cc of this posting sent to cited author via email]
This is current being discussed on the perl5-porters mailing list,
and will hopefully get fixed for the production 5.002 release.
No, please don't ask when unless you don't mind not getting an
answer. :-)
--tom
In comp.lang.perl.misc,
lbr@holos.com (Len Reed) writes:
:For the record, I'm running perl5.001m.
:
:On Linux I notice that caught signals are not reset; subsequent kills
:result in running the signal handler again. I see that this is because
:of hints/linux.sh, which defines __USE_BSD_SIGNAL. Without this defined,
:caught signal are reset to the default. (That was the behavior of signals
:in the original Unix systems.)
:
:I presume that BSD systems do not reset the signal handler, but my only
:evidence is the name "__USE_BSD_SIGNAL"; I do not have access to a BSD system.
:
:My two SVR4 systems (an AT&T GIS i486 systems and a Motorola 88k system)
:exhibit the old-style catch-and-reset behavior. SVR4 has a "sigset" function
:--unused by perl--that does signal handling without the reset junk.
:Since sigset has the same calling sequence as signal, the following should
:make SVR4 perl work like Linux:
: #define sigset signal
:
:Perl should provide consistent semantics across platforms
:inasmuch as it can. Consider waitpid, which is emulated by perl on
:platforms that don't really support it.
:
:I've always thought that the original Unix signal semantics were stupid,
:and so prefer the Linux perl to the SVR4. Furthermore, I would expect
:that changing SVR4 perl would break few scripts (who really depends on
:that automatic reset, anyway); changing Linux and BSD perl would like
:break a lot of things.
:
:Anyway, here's my suggestion:
:
:1) Configure should look for sigset in the C library; if found, cause
: the above #define to be done.
:2) Allow for hints override in case some system has a sigset that shouldn't
: be used.
:
:This won't make all platforms work alike; there are bound to be older Unix
:systems that don't support non-reseting signals at all. For those, I
:suggest another define:
:
:#define MUST_RESET_SIGNAL
:
:which would cause [new] code to automatically re-issue the signal call
:at the point that the C signal handler starts, before control is passed
:to the perl handler.
:
:This is a compromise, of course, since two quick signals can result
:in a dead process. That is why the old-style semantics were stupid.
:Detection of whether to set this #define would probably need to be done
:in a little test program run by Configure.
:--
:Len Reed
:lbr@holos.com
:Holos Software, Inc.
:Voice: (770) 496-1358 ext. 16
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
Of course, someone who knows more about this will correct me if I'm
wrong, and someone who knows less will correct me if I'm right.
This is current being discussed on the perl5-porters mailing list,
and will hopefully get fixed for the production 5.002 release.
No, please don't ask when unless you don't mind not getting an
answer. :-)
--tom
In comp.lang.perl.misc,
lbr@holos.com (Len Reed) writes:
:For the record, I'm running perl5.001m.
:
:On Linux I notice that caught signals are not reset; subsequent kills
:result in running the signal handler again. I see that this is because
:of hints/linux.sh, which defines __USE_BSD_SIGNAL. Without this defined,
:caught signal are reset to the default. (That was the behavior of signals
:in the original Unix systems.)
:
:I presume that BSD systems do not reset the signal handler, but my only
:evidence is the name "__USE_BSD_SIGNAL"; I do not have access to a BSD system.
:
:My two SVR4 systems (an AT&T GIS i486 systems and a Motorola 88k system)
:exhibit the old-style catch-and-reset behavior. SVR4 has a "sigset" function
:--unused by perl--that does signal handling without the reset junk.
:Since sigset has the same calling sequence as signal, the following should
:make SVR4 perl work like Linux:
: #define sigset signal
:
:Perl should provide consistent semantics across platforms
:inasmuch as it can. Consider waitpid, which is emulated by perl on
:platforms that don't really support it.
:
:I've always thought that the original Unix signal semantics were stupid,
:and so prefer the Linux perl to the SVR4. Furthermore, I would expect
:that changing SVR4 perl would break few scripts (who really depends on
:that automatic reset, anyway); changing Linux and BSD perl would like
:break a lot of things.
:
:Anyway, here's my suggestion:
:
:1) Configure should look for sigset in the C library; if found, cause
: the above #define to be done.
:2) Allow for hints override in case some system has a sigset that shouldn't
: be used.
:
:This won't make all platforms work alike; there are bound to be older Unix
:systems that don't support non-reseting signals at all. For those, I
:suggest another define:
:
:#define MUST_RESET_SIGNAL
:
:which would cause [new] code to automatically re-issue the signal call
:at the point that the C signal handler starts, before control is passed
:to the perl handler.
:
:This is a compromise, of course, since two quick signals can result
:in a dead process. That is why the old-style semantics were stupid.
:Detection of whether to set this #define would probably need to be done
:in a little test program run by Configure.
:--
:Len Reed
:lbr@holos.com
:Holos Software, Inc.
:Voice: (770) 496-1358 ext. 16
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
Of course, someone who knows more about this will correct me if I'm
wrong, and someone who knows less will correct me if I'm right.