develooper Front page | perl.perl5.porters | Postings from January 2003

RE: [perl #20613] Perl_magic_setsig/clearsig problems (patch included)

From:
Anders Johnson
Date:
January 31, 2003 01:16
Subject:
RE: [perl #20613] Perl_magic_setsig/clearsig problems (patch included)
Message ID:
000001c2c8b8$8d37b090$9800a8c0@wis.com
I think I see your point. Still, my vote would be to fix these issues to
the extent that we know about them. At worst, there are 442 instances of
SvREFCNT_dec to look at in the entire source tree.

OTOH, you can certainly make the argument that most of these bugs
require truly contrived cases to provoke, and therefore it isn't worth
the effort. However, the particular bug fixed by the patch was provoked
by an attempt to accumulate received signals in a critical section
block, and then deliver those signals to the process when the critical
section exits, which I think you'll agree is legitimate (but see below).

Incidentally, there are some related issues that I've recently
discovered:

+ If a signal is received just as you're changing its disposition from a
handler to DEFAULT, then the signal could get deferred until after the
disposition changes, which generally results in badness. (I already have
a patch for this one.)

+ It's still not safe for a signal handler to die() (which is otherwise
very useful), because it can prevent a DESTROY method from doing its
job. (This is analogous to the "destructors must never, ever throw" rule
in C++. See http://www.gotw.ca/gotw/047.htm .)

I think that fixing the second issue requires adding some
critical-section support to Perl itself. (Perhaps a $^E variable that
inhibits signal sampling and is automatically set locally for any
DESTROY and STORE methods that get called on behalf of a block exiting.)
If such a thing were to exist, then you could certainly call my test
case contrived, since you could then use "local $^E=1;" to accomplish
basically the same thing.

Of course, I'm all ears if you have any better ideas. I'm particularly
fond of any solution that doesn't require modifying the Perl core, so
long as it's clean and robust.

Thanks,
&ers






nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About