Mailing List Archive

> Hi- I had a question a while back about sleeping and selecting on the HP
> versus Sun, and got back an answer on how BSD's sleep differs from SYS V's. I
> came up with an improved test script that exits on test 3 on the HP platform
> perl5.001m that otherwise passes all other tests- runs OK under SunOS. I think
> I posted this updated test already, but didn't get a response. This could have
> somthing to do with our HP platform, I've only ever logged on to install perl,
> one perl program, and this script!

This program works *if* you do one thing -- reset the signal handler inside
the alarm_handler subroutine. A rather unfortunate consequence of System V
signal handlers.

> #!perl
>
> print "1..5\n";
>
> # Test the alarm mechanism
>

> sub alarm_handler {++$wentoff;}

sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}

> $SIG{'ALRM'}='alarm_handler';
> alarm 2;
> $interval = sleep 5;
>
> if ($interval >= 2 && $interval <= 3) {print "ok 1\n";}
> else {print "not ok 1 '$interval' should be 2 or 3 seconds\n";}
>
> select(undef, undef, undef, 1.1); # For BSD-ish sleeps
>
> if ($wentoff) {print "ok 2\n";}
> else {print "not ok 2 The alarm signal handler was not called.\n";}
>
> # Can alarm and select live together in harmony?
> alarm 1;
> select(undef, undef, undef, 1.1);
> if ($wentoff == 2) {print "ok 3\n";}
> else {print "not ok 3 The alarm handler wasn't called twice, even though the
> alarm was called twice.\n"}
>
> # Do some testing of select (and time)
>
> $start = time;
> ($num, $timeleft) = select (undef, undef, undef, 1.5);
> $interval = time - $start;
>
> if ($timeleft == 1.5 || $timeleft == 0) {print "ok 4\n";}
> else {print "not ok 3 '$timeleft' should be 0 or 1.5 seconds\n";}
>
> if ($interval >= 1 && $interval <= 2) {print "ok 5\n";}
> else {print "not ok 4 select should have waited between 1 and 2 seconds, not
> $interval seconds\n";}

Jeff

On Fri, 15 Sep 95 15:54:21 PDT Jeff Okamoto writ:
] This program works *if* you do one thing -- reset the signal handler inside
] the alarm_handler subroutine. A rather unfortunate consequence of System V
] signal handlers.
]
] > #!perl
] >
] > print "1..5\n";
] >
] > # Test the alarm mechanism
] >
]
] > sub alarm_handler {++$wentoff;}
]
] sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}

OK, that makes it work, but that's not how perl is documented... I now suggest
that the perlvar page that documents %SIG remind us that not all perls behave
the same with respect to signal re-handling. (Hey, QNX signals worked like
that... that was years ago for me...)

-yary

> sub alarm_handler {++$wentoff;}

sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}

actually, it's best to reset the handler as the first thing that
the handler does -- to try to protect against another signal
arriving before the handler is reset. of course, using sigset()
instead of signal() in this case is much better, as, sigset() has
similar sematics to the BSD signal. (of course, using posix
signal's would be a better method anyway).

.mrg.

(ps: you can't get to sigset() from perl normally.)

In <9509190023.AA13821@shawnee.raynet.com>
On Mon, 18 Sep 1995 17:23:11 -0700
Yary Hluchan <yhluchan@ops.raynet.com> writes:
>]
>] > sub alarm_handler {++$wentoff;}
>]
>] sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}
>
>OK, that makes it work, but that's not how perl is documented... I now suggest
>that the perlvar page that documents %SIG remind us that not all perls behave
>the same with respect to signal re-handling. (Hey, QNX signals worked like
>that... that was years ago for me...)
>
I think perl should be fixed so that $SIG{} behaved BSD/signal POSIX/sigaction
style - probably by using POSIX/sigaction if available, and re-enabling
signal in perl's C code on SYSV-ish machines.

> > sub alarm_handler {++$wentoff;}
>
> sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}
>
> actually, it's best to reset the handler as the first thing that
> the handler does -- to try to protect against another signal
> arriving before the handler is reset.

Yes, except for SIGC[H]LD, which under System V will produce an infinite loop
if you reset the handler immediately upon entering the handler routine.

Jeff

On Fri, 22 Sep 1995, Jeff Okamoto wrote:

> > > sub alarm_handler {++$wentoff;}
> >
> > sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}
> >
> > actually, it's best to reset the handler as the first thing that
> > the handler does -- to try to protect against another signal
> > arriving before the handler is reset.
>
> Yes, except for SIGC[H]LD, which under System V will produce an infinite loop
> if you reset the handler immediately upon entering the handler routine.

Sigh. I don't suppose there is any may for MetaConfig to distill all of
these non-portabilities into a unified standard? No? Didn't think so.

> Jeff

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

> > sub alarm_handler {++$wentoff;}
>
> sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}
>
> actually, it's best to reset the handler as the first thing that
> the handler does -- to try to protect against another signal
> arriving before the handler is reset.

Yes, except for SIGC[H]LD, which under System V will produce an infinite loop
if you reset the handler immediately upon entering the handler routine.

um... what difference does the placement of the resetter (nice word),
besides the amount of time that there won't be a handler? i mean,
i can't see why putting it at the end would _not_ cause an infinite
loop if putting it at the start would.

maybe i'm just not aware of Something.

.mrg.

According to matthew green:
> > Yes, except for SIGC[H]LD, which under System V will produce an infinite
> > loop if you reset the handler immediately upon entering the handler
> > routine.
>
> um... what difference does the placement of the resetter (nice word),
> besides the amount of time that there won't be a handler?

There's some side effect based on the fact that SIGCHLD isn't sent by
anyone, but is fabricated by the kernel when a child dies. It's a huge
kludge. But then, it _is_ SysV.

The most effective handling, so far as I know, is to loop in the handler
continuing to call waitpid() until it fails, and _then_ reset the handler.
--
Chip Salzenberg, aka <chs@nando.net>
"Hey, it's the Miss Alternate Universe Pageant!"
-- Crow T. Robot, MST3K: "Stranded In Space"

According to matthew green:
> > Yes, except for SIGC[H]LD, which under System V will produce an infinite
> > loop if you reset the handler immediately upon entering the handler
> > routine.
>
> um... what difference does the placement of the resetter (nice word),
> besides the amount of time that there won't be a handler?

There's some side effect based on the fact that SIGCHLD isn't sent by
anyone, but is fabricated by the kernel when a child dies. It's a huge
kludge. But then, it _is_ SysV.

all `unix' kernels as far as i know fabricate lots of signals. when a
session leader dies, a sighup is sent to that process group, for instance.

The most effective handling, so far as I know, is to loop in the handler
continuing to call waitpid() until it fails, and _then_ reset the handler.

um, what happens if two children die really close to each other, and,
say that the second one dies after the first signal has been delivered
to the parent, but before the parent has reset the signal handler ?
(possibly before the parent has even begun executing the signal handler
code at all).

i'm thinking of race conditions here. anyway, all modern systems have
posix signals, old bsd ones have real signal sematics, and, old sysv
systems (back to at least svr2, i believe, but, not further) have the
sigset() call, which, gives reliable signal behaviour, so, there shouldn't
really be _many_ cases that we don't have a reliable signal handling
interface available from the system level.

.mrg.

On Sat, 23 Sep 1995, Kenneth Albanowski wrote:

> On Fri, 22 Sep 1995, Jeff Okamoto wrote:
>
> > > > sub alarm_handler {++$wentoff;}
> > >
> > > sub alarm_handler {++$wentoff; $SIG{'ALRM'}='alarm_handler';}

> Sigh. I don't suppose there is any may for MetaConfig to distill all of
> these non-portabilities into a unified standard? No? Didn't think so.

Metaconfig does contain a d_keepsig.U unit. Here it is. Whether it's
what you want or not, I don't know.


?RCS: $Id: d_keepsig.U,v 3.0.1.4 1995/07/25 13:57:56 ram Exp $
?RCS:
?RCS: Copyright (c) 1991-1993, Raphael Manfredi
?RCS:
?RCS: You may redistribute only under the terms of the Artistic Licence,
?RCS: as specified in the README file that comes with the distribution.
?RCS: You may reuse parts of this distribution only within the terms of
?RCS: that same Artistic Licence; a copy of which may be found at the root
?RCS: of the source tree for dist 3.0.
?RCS:
?RCS: $Log: d_keepsig.U,v $
?RCS: Revision 3.0.1.4 1995/07/25 13:57:56 ram
?RCS: patch56: made cc and ccflags optional dependencies
?RCS:
?RCS: Revision 3.0.1.3 1995/01/11 15:26:25 ram
?RCS: patch45: protected "sh -c" within backquotes for Linux and SGI
?RCS:
?RCS: Revision 3.0.1.2 1994/10/29 16:13:59 ram
?RCS: patch36: call ./bsd explicitely instead of relying on PATH
?RCS:
?RCS: Revision 3.0.1.1 1993/10/16 13:48:47 ram
?RCS: patch12: comment for SIGNALS_KEPT was the other way round
?RCS:
?RCS: Revision 3.0 1993/08/18 12:06:26 ram
?RCS: Baseline for dist 3.0 netwide release.
?RCS:
?MAKE:d_keepsig: cat +cc +ccflags rm Guess contains echo n c Setvar
?MAKE: -pick add $@ %<
?S:d_keepsig:
?S: This variable contains the eventual value of the SIGNALS_KEPT symbol,
?S: which indicates to the C program if signal handlers need not reinstated
?S: after receipt of a signal.
?S:.
?C:SIGNALS_KEPT (PERSISTENT_SIGNAL):
?C: This symbol is defined if signal handlers needn't be reinstated after
?C: receipt of a signal.
?C:.
?H:#$d_keepsig SIGNALS_KEPT /**/
?H:.
?LINT:set d_keepsig
: see if signals are kept
val="$undef";
echo " "
echo "Checking to see if signal handlers stick around..." >&4
$cat >try.c <<'EOCP'
foo() {}

main()
{
signal(2, foo);
kill(getpid(), 2);
kill(getpid(), 2);
printf("abc\n");
}
EOCP
if $cc -o try $ccflags try.c >/dev/null 2>&1; then
?X: On AIX a single ./try will not work (with ksh)
?X: Backquotes required on Linux and SGI (prevents "ambiguous output redirect")
?X: (reported by Xavier LeVourch <xavierl@eiffel.com>)
`sh -c ./try >try.out 2>/dev/null`
if $contains abc try.out >/dev/null 2>&1; then
echo "Yes, they do."
val="$define";
else
echo "No, they don't."
fi
else
$echo $n "(I can't seem to compile the test program. Assuming $c"
if ./bsd; then
echo "they do.)"
val="$define"
else
echo "they don't.)"
fi
fi
set d_keepsig
eval $setvar
$rm -f try*


Andy Dougherty doughera@lafcol.lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042

On Wed, 4 Oct 1995, Andy Dougherty wrote:

> Metaconfig does contain a d_keepsig.U unit. Here it is. Whether it's
> what you want or not, I don't know.

Partially, I think. Now it just needs to also check each signal
independantly (to catch SIGCHLD, etc.), see if POSIX signal handling is
available, and set up some #defines so that signals handlers can easily
and portably be written that don't need restarting and have defined
semantics.

It's a good start, though. :-)

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

> Once we agree on the symbols we want, and the methods to be used to compute
> things, it's a matter of me finding the time to write the unit and you
> the time to test it on a variety of platforms ;-)

I'll volunteer the time on the HP platform.

Jeff

Quoting Kenneth Albanowski:
:On Wed, 4 Oct 1995, Andy Dougherty wrote:
:
:> Metaconfig does contain a d_keepsig.U unit. Here it is. Whether it's
:> what you want or not, I don't know.
:
:Partially, I think. Now it just needs to also check each signal
:independantly (to catch SIGCHLD, etc.), see if POSIX signal handling is
:available, and set up some #defines so that signals handlers can easily
:and portably be written that don't need restarting and have defined
:semantics.

I promised Tom I'd investigate this and provide a reasonable metaconfig
support (like I did for non-blocking I/O). Any input or contribution
is welcome. In which case, it might be good to move the discussion
to dist-users@foretune.co.jp.

Once we agree on the symbols we want, and the methods to be used to compute
things, it's a matter of me finding the time to write the unit and you
the time to test it on a variety of platforms ;-)

Raphael