Re: Fragile signals
authorIlya Zakharevich <ilya@math.ohio-state.edu>
Thu, 13 Feb 1997 06:44:39 +0000 (01:44 -0500)
committerChip Salzenberg <chip@atlantic.net>
Tue, 18 Feb 1997 01:22:00 +0000 (13:22 +1200)
commit09df8c7df7dfc9853902f1fdd8a6d95f53be66fc
tree686d9ef4146d6bad4a386896e98a90a79280d43f
parent3d2573a84a1aa655d5da58c57b3fc20e04d40f9f
Re: Fragile signals

Ilya Zakharevich writes:
>
> Some messages of mine get stuck in the chain:
>
>         Nico => Debian => floor
>
> I repost them now:
>
> As you may remember, the following program
>
> #!/usr/bin/perl
> sub foo { ++$a }
> $SIG{ALRM} = sub { $run = 0 ; return };
> while (1) {
>   $a = 0;
>   $run = 1;
>   alarm 1;
>   foo while $run;
>   print $i++, ": $a\n";
> }
> die "Not reached";
> __END__
>
> will not call malloc/realloc/free in sighandler, but nevertheless it
> would not run more than approx. 25 iterations. This shows that 4% of
> subroutine-calling frame is not signal-safe.
>
> The following patch makes it run approx. twice as long (on _17) (thus

Well, the following patch makes it run 4 times as long. The only
failure mode I have seen was silent walking off runops().

Here is the statistics (number of iterations before failure):

   Before:
                23, 24, 14, 22, 19, 13, 30, 11
        (4 core dumps, 2 attempts to free unref scalar, 1 panic:
                leave-scope, 1 silent)
   After:
                42, 936, 63, 131, 280.
        (all silent)

It looks like handling of internal stacks needs a lot of
improvement. What this patch does is only a symptomatic treatment, but
it may go into 004 nevertheless (especially if one can see why op
becomes 0 at some moment). I tried saving/restoring op in the handler,
but this does not help...

p5p-msgid: <199702130644.BAA07572@monk.mps.ohio-state.edu>
mg.c