Mailing List Archive

Do we have a policy on this?

Tim.

In article <4bcjv8$noq@kadath.zeitgeist.net> you write:
> I have a program that sets $SIG{'PIPE'}. It runs fine and catches the SIGPIPE
> with no problem, once. After that it doesn't seem to get the signal. I found
> the following in the FAQ but I'm not running Solaris. (uname -a => SunOS
> mojones 4.1.1 7 sun4. Perl is version 5.001m.) Do I, nonetheless, have the
> same problem or is something else wrong? If it is the same problem, is the fix
> given the recommended solution.
>
> Michael D'Errico* reports:
>
> If you are using Solaris 2.x, the signal handling is broken. If
> you set up a signal handler such as 'ripper' it will be forgotten
> after the first time the signal is caught. To fix this, you need
> to recompile Perl. Just add '#define signal(x,y) sigset((x),(y))'
> after the '#include <signal.h>' directive in each file that it
> occurs, then make it again.
>
> Thanks,
> Peter
>
> --
>
> Peter Seibel seibel@mojones.com
> Writer/Perl Hacker 510-482-9105

Do we have a policy on this?

Tim.

In article <4bcjv8$noq@kadath.zeitgeist.net> you write:
> I have a program that sets $SIG{'PIPE'}. It runs fine and catches the SIGPIPE
> with no problem, once. After that it doesn't seem to get the signal. I found
> the following in the FAQ but I'm not running Solaris. (uname -a => SunOS
> mojones 4.1.1 7 sun4. Perl is version 5.001m.) Do I, nonetheless, have the
> same problem or is something else wrong? If it is the same problem, is the fix
> given the recommended solution.
>
> Michael D'Errico* reports:
>
> If you are using Solaris 2.x, the signal handling is broken. If
> you set up a signal handler such as 'ripper' it will be forgotten
> after the first time the signal is caught. To fix this, you need
> to recompile Perl. Just add '#define signal(x,y) sigset((x),(y))'
> after the '#include <signal.h>' directive in each file that it
> occurs, then make it again.
>
> Thanks,
> Peter
>
> --
>
> Peter Seibel seibel@mojones.com
> Writer/Perl Hacker 510-482-9105

>Do we have a policy on this?

Yup: it's that "we wish it worked" but no one
has sent in the patches yet to make it so.

--tom

On Fri, 22 Dec 1995, Nick Ing-Simmons wrote:

> In <819637030.3979.1@ignite.demon.co.uk>
> On Fri, 22 Dec 1995 12:32:02 +0000
> Tim Bunce <Tim.Bunce@ig.co.uk> writes:
> >Do we have a policy on this?
> >
> >Tim.
>
> I can see two possible policies:
>
> 1. %SIG does whatever your OS's signal() does (as now).
>
> 2. %SIG behaves as per BSD or POSIX
> either by using sigset/sigaction (if available), or by explcitly
> re-installing the handler in the C part of perl's handler.
>
> The hard part of (2) is Configure support.

I've started taking a look at fixing this up. Stevens' UNIX book has
proved quite voluble on the subject.

Making signal() use POSIX routines is possible, although they could be
hacked directly into mg.c just as easily.

A rather nasty bit I see is that if reliable signals aren't available, and
we reinstall the handler, then we must be _very_ carefull that SIGCLD (or
SIGCHLD, whichever is being used) doesn't have classic (and fatal)
semantics. Does anyone know that their machine works this way? (The
problem is where reenabling SIGCLD will _immediately_ fire off a call to
the signal handler if a child process is around, even if we are already in
a signal handler. You have to run wait() first to reap the child before
you can safely reenable the signal.)

The sequence of events to work past this is feasible, but ugly:

1. process $SIG{} assignment as usual (call signal).

2. on signal handler invocation, immediately call signal again, unless we
got called for SIGCLD, in which case set global flag.

3. on return from wait() or waitpid(), check aforementioned flag, and if
it's set then call signal again and reset the flag.

Note that there _still_ seems to be one unanswered question about signals,
and that's whether a signal firing while a signal handler is running is
blocked (to be fired when the handler exits) or is active, and will
trigger a recursive handler. With modern POSIX signal handling, you can
choose between these behaviours, but with old unreliable signals, you need
another layer of flags to approximate blocked signals. (A layer that perl
currently doesn't have.)

It seems to me that blocking semantics are appropriate, but are definitely
more work. (Also, it seems like it would then be nice to have commands to
manually set, reset, and query the blocking status, but that's also more
work.)

Any comments, especially porting concerns, or direction statements, would
be appreciated.

Oh, and by the way, if you are of the persuasion: Merry Christmas!

If not: Happy Holidays!

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> A rather nasty bit I see is that if reliable signals aren't available, and
> we reinstall the handler, then we must be _very_ carefull that SIGCLD (or
> SIGCHLD, whichever is being used) doesn't have classic (and fatal)
> semantics. Does anyone know that their machine works this way?

HP-UX's signal(2) behaves in this manner.

> Note that there _still_ seems to be one unanswered question about signals,
> and that's whether a signal firing while a signal handler is running is
> blocked (to be fired when the handler exits) or is active, and will
> trigger a recursive handler.

In HP-UX with signal(2), sending a signal within a signal handler triggers
the next handler.

Jeff

On Tue, 26 Dec 1995, Jeff Okamoto wrote:

> > A rather nasty bit I see is that if reliable signals aren't available, and
> > we reinstall the handler, then we must be _very_ carefull that SIGCLD (or
> > SIGCHLD, whichever is being used) doesn't have classic (and fatal)
> > semantics. Does anyone know that their machine works this way?
>
> HP-UX's signal(2) behaves in this manner.

Including the immediate re-issuing of SIGCLD?

> > Note that there _still_ seems to be one unanswered question about signals,
> > and that's whether a signal firing while a signal handler is running is
> > blocked (to be fired when the handler exits) or is active, and will
> > trigger a recursive handler.
>
> In HP-UX with signal(2), sending a signal within a signal handler triggers
> the next handler.

Next handler? The default, or the current handler? Or does HP-UX have some
mechanism for stacking handlers that I'm not familiar with?

> Jeff
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> > HP-UX's signal(2) behaves in this manner.
>
> Including the immediate re-issuing of SIGCLD?

Yes.

> > In HP-UX with signal(2), sending a signal within a signal handler triggers
> > the next handler.
>
> Next handler? The default, or the current handler? Or does HP-UX have some
> mechanism for stacking handlers that I'm not familiar with?

Here's a short code example. As soon as the SIGUSR2 signal is sent, the
handler for that signal is called, despite already being in a handler for
SIGUSR1.

Jeff
-----
#include <stdio.h>
#include <signal.h>

void usr1(), usr2();

main()
{
signal(SIGUSR1, usr1);
signal(SIGUSR2, usr2);
fprintf(stderr, "Sending USR1\n");
kill(0, SIGUSR1);
fprintf(stderr, "Sent USR1\n");
fprintf(stderr, "Exiting\n");
}

void
usr1()
{
fprintf(stderr, "Inside usr1, sending USR2\n");
kill(0, SIGUSR2);
fprintf(stderr, "Sent USR2\n");
fprintf(stderr, "Leaving usr1\n");
}

void
usr2()
{
fprintf(stderr, "Inside usr2\n");
fprintf(stderr, "Leaving usr2\n");
}

> Oh, communications failure: what happens when SIGUSR1 is raised inside
> the SIGUSR1 handler? Recursion, or blocking?

No, it simply exits with "Signal 16". Apparently in SysV, once you're
inside a handler, you must *first* reassert the handler *unless* it's
a SIGCLD handler. This leaves a window in which a program could die
because it received a second signal before the handler could be reinstated.

Jeff

On Tue, 26 Dec 1995, Jeff Okamoto wrote:

> > > HP-UX's signal(2) behaves in this manner.
> >
> > Including the immediate re-issuing of SIGCLD?
>
> Yes.

Ick. Well, thanks, that confirms that this is an active problem that
needs to be compensated for.

> Here's a short code example. As soon as the SIGUSR2 signal is sent, the
> handler for that signal is called, despite already being in a handler for
> SIGUSR1.

Oh, communications failure: what happens when SIGUSR1 is raised inside
the SIGUSR1 handler? Recursion, or blocking?

> Jeff

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Tue, 26 Dec 1995, Jeff Okamoto wrote:

> No, it simply exits with "Signal 16". Apparently in SysV, once you're
> inside a handler, you must *first* reassert the handler *unless* it's
> a SIGCLD handler. This leaves a window in which a program could die
> because it received a second signal before the handler could be reinstated.

Come to think of it, I knew that. On systems with unreliable signals,
signals will not be blocked during execution of the handler, and can, in
theory, reenter the handler. (In theory, because I'm not certain that the
double reentrancy is specified behavior.)

I think the question I need answered is: on systems with reliable signals
(_not_ HP-UX, evidentally), and I mean signal(), not POSIX sigaction(),
etc. are signals blocked during execution of the handler. E.g., does
raising SIGUSR1 inside a SIGUSR1 handler cause the handler to immediatly
recurse, does it cause the second signal to be lost, or will the handler
trigger after it finishes handling the original signal?

> Jeff

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> I think the question I need answered is: on systems with reliable signals
> (_not_ HP-UX, evidentally), and I mean signal(), not POSIX sigaction(),
> etc. are signals blocked during execution of the handler. E.g., does
> raising SIGUSR1 inside a SIGUSR1 handler cause the handler to immediatly
> recurse, does it cause the second signal to be lost, or will the handler
> trigger after it finishes handling the original signal?

On HP-UX, the answer is "none of the above". Upon entering a signal handler,
the action is restored to SIGDFLT, so for most signals, sending a second
instance of the same signal while inside the first one's handler will cause
the program to terminate unless the first action you take inside the handler
is to restore the handler.

Jeff

On Tue, 26 Dec 1995, Jeff Okamoto wrote:

> On HP-UX, the answer is "none of the above". Upon entering a signal handler,
> the action is restored to SIGDFLT, so for most signals, sending a second
> instance of the same signal while inside the first one's handler will cause
> the program to terminate unless the first action you take inside the handler
> is to restore the handler.

And, as we know, there is a race condition there. So be it.

If we want reliable (or as reliable as possible) signals on all systems,
with optional blocking of recursing signals, it's looking like the
following things need to be done:

1. If possible, call POSIX signal functions instead of traditional
signal(). This fixes everything without any further problems, and the rest
of the steps can be ignored. This change should be quite simple.

2. In Configure, figure out whether signal() is reliable or not.

3. If signal() is reliable (doesn't reset to SIGDFLT on entry to handler)
then figure out whether they are blocking or not.

4. If signal() isn't reliable, figure out whether SIGCLD has dangerous
semantics.

For the rest of the steps, skip the sigblock[] stuff if signals are
already blocking. Skip the SIGCLD stuff if SIGCLD has normal semantics.

5. Create a new internal array that records whether a signal handler is
currently running. This allows us to simulate blocking semantics on
systems that don't normally do this.

6. Change signal_handler (read up on this in mg.c) so that it looks
something like this:

signal_handler(int signo) {
sigblock[signo]++;
resignal(signo) unless signo == SIGCLD;
return if sigblock[signo] != 1;

again:
call perl signal handler;

if(--sigblock[signo]) {
sigblock[signo]=1;
goto again;
}
}

Specifically, the sigblock[] array is used both to block recursive calls
to the handler, and to record that such a call has happened. This
probably could be written better.

There is one spot of worry I have here, and that's abnormal exits from the
signal_handler. I'm not exactly sure where longjmp() comes into play, but
if it is used at all then the signal will get permanently blocked. This
isn't that great of an idea.

7. Change pp_wait|pp_waitpid so that if SIGCLD has previous fired, redo
the signal() after the syscall has returned. I suppose a global flag is
needed here, although I suppose this might also be overlayed into the
sigblock[] array somehow.

--

If anyone knows enough about this subject to offer help, I'd greatly
appreciate it. As porting goes, this is a relatively simple (hah!) area,
which can be readily improved, but I'm not confident that I know all the
needed tricks to do it properly.

Note that step #1 above is the simplest, and can be done without worrying
about the rest.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Tue, 26 Dec 1995, Kenneth Albanowski wrote:

> If we want reliable (or as reliable as possible) signals on all systems,
> with optional blocking of recursing signals, it's looking like the
> following things need to be done:
>
> 1. If possible, call POSIX signal functions instead of traditional
> signal(). This fixes everything without any further problems, and the rest
> of the steps can be ignored. This change should be quite simple.

This is probably all you really need to do. Since almost everyone tries
to just use Configure -d, and since POSIX is tried by default, I tend to
hear about systems where POSIX doesn't work (and, by implication, about
systems where POSIX signals aren't available.)

A quick tour through the hints directory finds the following four systems
unable to compile POSIX for whatever reasons:

Mach Ten (BSD-ish ??)
ncr_tower (System Vr2)
Next 3.0 (BSD-ish)
Titanos (???)

(Jarkko may be able to tell us about Titanos)

Of those systems, probably only ncr_tower (SVR2) has System V signals.
The reset probably have BSD style signal handlers (though why the
Berkeley folks used the same name for a different function is beyond me).
If memory serves, SVR2 has POSIX-ish signals.

In short, a sequence
#ifdef HAS_SIGACTION /* or whatever it should be */
use sigaction or whatever
#else
use signal
#endif
will probably get you 99.4% of the way there. Only SVR1 (or v7
derivatives :-) systems would possibly need further modification.

I've never used POSIX signal functions, so I'm wary of trying to do this
myself quickly, but if someone else wants to patch mg.c, pp_sys.c, and
util.c, I'll supply the Configure HAS_SIGACTION test (or whatever it
should be).

I'd skip steps 2-7 until there's a proven need.

Andy Dougherty doughera@lafcol.lafayette.edu

> Or at least, I _think_ it's sufficient. I have not yet managed to
> comprehend the flow of control through the perl interpreter, when
> combined with longjmp(). If perl is using setjmp() at some point before a
> signal handler is entered, and using longjmp() at all non-local exits
> from that signal handler, then replacing them with sig-jmp should work
> fine. If perl doesn't get the scope on these right, then there could be
> some problems.

Let's make sure that we don't re-introduce the problem that Perl 4 had
with longjmp clobbering register variables that was solved with the
JMPCLOBBER define.

Jeff

On Thu, 28 Dec 1995, Jack Shirazi wrote:

>
> > There is one spot of worry I have here, and that's abnormal exits from the
> > signal_handler. I'm not exactly sure where longjmp() comes into play, but
> > if it is used at all then the signal will get permanently blocked. This
> > isn't that great of an idea.
>
> This has hit me in two ways previously. In SG-IRIX, there is an OS bug which means
> that when I use POSIX signal blocking and die, the signal block gets locked. In my
> EventDriven server, I have control (I always know when this could happen) so that I
> automatically unblock when I come into this situation. Its only happened on the SG so far.
> The reports and workarounds are somewhere in the pp archives.

Thank you, for demonstrating one problem! :-)

This, in theory, can be solved by using sigsetjmp() and siglongjmp()
instaed of setjmp() and longjmp().

If SG-IRIX doesn't have those functions, we need to talk...

> Another situation is when using handlers, I can sometimes get a die to propagate
> past the eval. Thats not an IRIX bug - it happened on all the systems I tested.
> Unfortunately I never had the time to isolate the code to do this, but I suspect its
> an artifact of the above description.

That should be a separate (though of course unfortunate) problem from
signal handling.

> --
> Jack Shirazi

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Thu, 28 Dec 1995, Andy Dougherty wrote:

> In short, a sequence
> #ifdef HAS_SIGACTION /* or whatever it should be */
> use sigaction or whatever
> #else
> use signal
> #endif
> will probably get you 99.4% of the way there. Only SVR1 (or v7
> derivatives :-) systems would possibly need further modification.

Care to expand on this? I'm far more familiar with POSIX then SVR or BSD.

> I've never used POSIX signal functions, so I'm wary of trying to do this
> myself quickly, but if someone else wants to patch mg.c, pp_sys.c, and
> util.c, I'll supply the Configure HAS_SIGACTION test (or whatever it
> should be).

I'm talking with Raphael about this. HAS_SIGACTION gets us most of the
way, but we also need to deal with sigsetjmp()/siglongjmp(), as Jack has
mentioned. The patch I sent out for mg.c has the sigaction changes, and I
should be able to whip up the sig-jmp changes in a jiffie. That should
indeed be sufficient.

Or at least, I _think_ it's sufficient. I have not yet managed to
comprehend the flow of control through the perl interpreter, when
combined with longjmp(). If perl is using setjmp() at some point before a
signal handler is entered, and using longjmp() at all non-local exits
from that signal handler, then replacing them with sig-jmp should work
fine. If perl doesn't get the scope on these right, then there could be
some problems.

On a more subtle note, I don't know whether longjmp() is used properly in
the case where two signal handlers are running recursively, and a
non-local exit is performed from inside the second one to inside the first
one. Getting this wrong could cause temporary masking glitches.

> I'd skip steps 2-7 until there's a proven need.

Agreed.

> Andy Dougherty doughera@lafcol.lafayette.edu

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Thu, 28 Dec 1995, Jeff Okamoto wrote:

> > Or at least, I _think_ it's sufficient. I have not yet managed to
> > comprehend the flow of control through the perl interpreter, when
> > combined with longjmp(). If perl is using setjmp() at some point before a
> > signal handler is entered, and using longjmp() at all non-local exits
> > from that signal handler, then replacing them with sig-jmp should work
> > fine. If perl doesn't get the scope on these right, then there could be
> > some problems.
>
> Let's make sure that we don't re-introduce the problem that Perl 4 had
> with longjmp clobbering register variables that was solved with the
> JMPCLOBBER define.

I'm not familiar with that problem, and "JMPCLOBBER" doesn't seem to be
contained anywhere in perl5. Likely the interpreter is designed
differently so the problem doesn't occur.

> Jeff

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Thu, 28 Dec 1995, Jack Shirazi wrote:

> These are the reports (at least those that I could find in my archives) that I made
> to the list:

Thanks very much. This test case is indeed sufficient.

> I think you get this sort of difference because of the differences in
> longjmp, which acts like _longjmp on some platforms, and siglongjmp on
> others.
>
> But then I'm not a real C programmer, so this could all be rubbish.

Absolutely correct (er, about the cause of the problem, not the rubbish
:-). With the POSIX signal patch I just posted, siglongjmp will be used if
available, and the problem (which can be stimulated under Linux with a bit
of work) goes away.

> -- Jack Shirazi, JackS@slc.com

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> There is one spot of worry I have here, and that's abnormal exits from the
> signal_handler. I'm not exactly sure where longjmp() comes into play, but
> if it is used at all then the signal will get permanently blocked. This
> isn't that great of an idea.

This has hit me in two ways previously. In SG-IRIX, there is an OS bug which means
that when I use POSIX signal blocking and die, the signal block gets locked. In my
EventDriven server, I have control (I always know when this could happen) so that I
automatically unblock when I come into this situation. Its only happened on the SG so far.
The reports and workarounds are somewhere in the pp archives.

Another situation is when using handlers, I can sometimes get a die to propagate
past the eval. Thats not an IRIX bug - it happened on all the systems I tested.
Unfortunately I never had the time to isolate the code to do this, but I suspect its
an artifact of the above description.

--
Jack Shirazi
Consulting Services Manager
GemStone Systems (Europe)
Phone: +44 171 872 5749
Email: JackS@slc.com

> Mach Ten (BSD-ish ??)
> ncr_tower (System Vr2)
> Next 3.0 (BSD-ish)
> Titanos (???)
>
> (Jarkko may be able to tell us about Titanos)

Ummm. I no more have an account there so all this is from memory:
TitanOS is an old mongrel, primarily SysV (I'd day SVR1 if there is
such a thing), bits of BSD (4.1/4.2 or so) thrown in. The signaling
system is sigblock()/sighold()/sigrelse()-ish.

++jhi;

On Fri, 29 Dec 1995, Jarkko Hietaniemi wrote:

>
> > Mach Ten (BSD-ish ??)
> > ncr_tower (System Vr2)
> > Next 3.0 (BSD-ish)
> > Titanos (???)
> >
> > (Jarkko may be able to tell us about Titanos)
>
> Ummm. I no more have an account there so all this is from memory:
> TitanOS is an old mongrel, primarily SysV (I'd day SVR1 if there is
> such a thing), bits of BSD (4.1/4.2 or so) thrown in. The signaling
> system is sigblock()/sighold()/sigrelse()-ish.

Ugh. If that's anything like I think it is (specifically including
sigset() and SIG_HOLD) then nothing useful like siglongjmp() exists. I
_think_ it could be emulated by capturing the held state (via
sigset(no,state=sigset(no,SIG_HOLD));) in a custom setjmp(), but this is
hardly pretty.

> ++jhi;


--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

Kenneth Albanowski writes:
> > > Titanos (???)
> > > (Jarkko may be able to tell us about Titanos)
> > Ummm. I no more have an account there so all this is from memory:
> > TitanOS is an old mongrel, primarily SysV (I'd day SVR1 if there is
> > such a thing), bits of BSD (4.1/4.2 or so) thrown in. The signaling
> > system is sigblock()/sighold()/sigrelse()-ish.
> Ugh. If that's anything like I think it is (specifically including
> sigset() and SIG_HOLD) then nothing useful like siglongjmp() exists. I
> _think_ it could be emulated by capturing the held state (via
> sigset(no,state=sigset(no,SIG_HOLD));) in a custom setjmp(), but this is
> hardly pretty.

If you have some test programs I think I could ask an acquaintance of
mine to run them. Don't hold your breath, though, in _URGENT_ cases
you can get an answer from him maybe even within a month :-)

++jhi;

On Fri, 29 Dec 1995 01:35:55 +0200, Jarkko Hietaniemi wrote:
>
>Kenneth Albanowski writes:
> > > > Titanos (???)
> > > > (Jarkko may be able to tell us about Titanos)
> > > Ummm. I no more have an account there so all this is from memory:
> > > TitanOS is an old mongrel, primarily SysV (I'd day SVR1 if there is
> > > such a thing), bits of BSD (4.1/4.2 or so) thrown in. The signaling
> > > system is sigblock()/sighold()/sigrelse()-ish.
> > Ugh. If that's anything like I think it is (specifically including
> > sigset() and SIG_HOLD) then nothing useful like siglongjmp() exists. I
> > _think_ it could be emulated by capturing the held state (via
> > sigset(no,state=sigset(no,SIG_HOLD));) in a custom setjmp(), but this is
> > hardly pretty.
>
>If you have some test programs I think I could ask an acquaintance of
>mine to run them. Don't hold your breath, though, in _URGENT_ cases
>you can get an answer from him maybe even within a month :-)
>

I have access to a Stardent here running TitanOS 3000 (that's right, still
an arcane SysV, with some bad, broken, BSD bits thrown in), so I could
probably run them for you. The last time I compiled perl on that
monster, it was 5.000, and POSIX wouldn't.

But if you ask what I _really_ think, we shouldn't bother with working hard
on trying to support an OS that's been long "dead". Atleast, Kubota is no
more, and the machines I know are in a state of pitiful disrepair.

- Sarathy.
gsar@engin.umich.edu

> > This has hit me in two ways previously. In SG-IRIX, there is an OS bug which means
> > that when I use POSIX signal blocking and die, the signal block gets locked. In my
> > EventDriven server, I have control (I always know when this could happen) so that I
> > automatically unblock when I come into this situation. Its only happened on the SG so far.
> > The reports and workarounds are somewhere in the pp archives.
>
> Do you have some _simple_ perl code to demonstrate this? It's doesn't seem
> very easy to trigger in perl.

These are the reports (at least those that I could find in my archives) that I made
to the list:

Message-Id: <9506161553.AA21188@bison.lif.icnet.uk>
Date: Fri, 16 Jun 95 16:53:14 BST
>From: js@biu.icnet.uk (Jack Shirazi - BIU)
To: perl5-porters@africa.nicoh.com
Subject: Problem with POSIX signals and signal masks on IRIX

The following prog apparently acts incorrectly on IRIX. It installs an
Alarm handler with a full signal mask, then does the various kills. On
SunOS this correctly produces 4 'here's and then a 'Terminated'. This
also is what happens on IRIX if you use the 'a' signal handler. But if
you use the 'b' one, then all signals after the first are blocked. If
you comment out the 'fillset' line, then only the ALRM signals are
blocked after the first one. All this leads me to think that on IRIX,
when the handler is called, the signal mask that is specified by the
sigaction call while the handler is operating is used, but that if the
process 'dies' in the handler, then the sigmask is NOT restored to the
pre-handler state. So every time a handler gets called and died out of,
at least its signal (and whatever others were specified in the mask) is
going to get added to the signal mask.

I think you get this sort of difference because of the differences in
longjmp, which acts like _longjmp on some platforms, and siglongjmp on
others.

But then I'm not a real C programmer, so this could all be rubbish.

I tried this with both 5.000 and 5.001l.


#!perl
require POSIX;

$FULL_MASK = POSIX::SigSet->new();
$FULL_MASK->fillset();
$H = 'a';
$H = 'b';

sub a {warn "here\n";}
sub b {warn "here\n";die;}

sub t1 {
POSIX::sigaction(POSIX::SIGALRM() ,POSIX::SigAction->new($H,$FULL_MASK));
eval {kill 'ALRM',$$} ;
eval {kill 'ALRM',$$} ;
eval {kill 'ALRM',$$} ;
eval {kill 'ALRM',$$} ;
eval {kill 'TERM',$$} ;
}

t1();
__END__

output of myconfig:
Summary of my perl5 (patchlevel 1) configuration:
Platform:
osname=irix, osver=5, archname=IP22-irix
uname='irix sgi 5.2 02282016 ip22 mips '
hint=recommended
Compiler:
cc='cc', optimize='-O', ld='ld'
cppflags='-D_POSIX_SOURCE -ansiposix -D_BSD_TYPES'
ccflags ='-D_POSIX_SOURCE -ansiposix -D_BSD_TYPES -Olimit 3000'
ldflags =''
stdchar='unsigned char', d_stdstdio=define, usevfork=false
voidflags=15, castflags=1, d_casti32=define, d_castneg=undef
intsize=4, alignbytes=8, usemymalloc=y, randbits=15
Libraries:
so=so
libpth=/usr/lib /usr/local/lib /lib
libs=-lsun -lm -lc -lcrypt -lbsd -lPW
libc=/usr/lib/libc.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef
cccdlflags=' ', ccdlflags=' ', lddlflags='-shared'

Message-Id: <9506190913.AA25086@bison.lif.icnet.uk>
Date: Mon, 19 Jun 95 10:13:32 BST
>.From: js@biu.icnet.uk (Jack Shirazi - BIU)
To: perl5-porters@africa.nicoh.com
Subject: Re: Problem with POSIX signals and signal masks on IRIX

I wrote that the following prog doesn't work correctly in IRIX - the problem
being that a die in a signal handler leaves that signal blocked. I'm using
the following as a workaround:

After any eval, check $@ and if its true, reset the signal mask, i.e.
$@ && POSIX::sigprocmask(POSIX::SIG_UNBLOCK(),$FULL_MASK);

> #!perl
> require POSIX;
>
> $FULL_MASK = POSIX::SigSet->new();
> $FULL_MASK->fillset();
> $H = 'a';
> $H = 'b';
>
> sub a {warn "here\n";}
> sub b {warn "here\n";die;}
>
> sub t1 {
> POSIX::sigaction(POSIX::SIGALRM() ,POSIX::SigAction->new($H,$FULL_MASK));
> eval {kill 'ALRM',$$} ;
> eval {kill 'ALRM',$$} ;
> eval {kill 'ALRM',$$} ;
> eval {kill 'ALRM',$$} ;
> eval {kill 'TERM',$$} ;
> }
>
> t1();
> __END__


-- Jack Shirazi, JackS@slc.com