This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
add a new function, Perl_perly_sighandler()
authorDavid Mitchell <davem@iabyn.com>
Mon, 11 Nov 2019 11:26:45 +0000 (11:26 +0000)
committerDavid Mitchell <davem@iabyn.com>
Mon, 18 Nov 2019 09:34:40 +0000 (09:34 +0000)
commit8a5e470b690b1c90c7332e613ada153af5547505
tree09fa828dea2835b597859bf56f6da0362c84089d
parent5e7940ceb0d598dfa2aefdcdbda1f1dd8caa6bfd
add a new function, Perl_perly_sighandler()

This function implements the body of what used to be Perl_sighandler(),
the latter becoming a thin wrapper round Perl_perly_sighandler().

The main reason for this change is that it allows us to add an extra
arg, 'safe' to the function without breaking backcompat. This arg
indicates whether the function is being called directly from the OS
signal handler (safe==0), or deferred via Perl_despatch_signals()
(safe==1).

This allows an infelicity in the code to be fixed - it was formerly
trying to determine the route it had been called by (and hence whether a
'safe' route) by seeing if either of the sig/uap parameters was
non-null. It turns out that this was highly dogdy, and only worked by
luck. The safe caller did indeed pass NULL args, but due to a bug
(shortly to be fixed), sometimes the kernel thinks its calling a 1-arg
sig handler when its actually calling a 3-arg one. This means that the
sig/uap args are random garbage, and happen to be non-zero only by happy
coincidence on the OS/platforms so far.

Also, it turns out that the call via Perl_csighandler() was getting it
wrong: its explicit (NULL,NULL) args made it look like a safe signal
call. This will be corrected in the next commit, but for this commit the
old wrong behaviour is preserved.

See RT #82040 for details of when/why the original dodgy 'safe' check
was
added.
embed.fnc
embed.h
mg.c
proto.h