[perl #92246] Perl 5.14 does not allow "internal" setting of $ENV{'PERL_SIGNALS'}

[Cameron Kaiser]

# New Ticket Created by Cameron Kaiser
# Please include the string: [perl #92246]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=92246 >

A common idiom, at least in my code, is to have the script itself set
$ENV{'PERL_SIGNALS'} = "unsafe", such as in BEGIN { }, so that I don't have
to pollute my environment with it ordinarily and the scripts that want this
can set it themselves. This works fine in 5.8, 5.10 and 5.12. It does not
work in 5.14; it requires that I already have the variable set before the
script is executed, or the value is not seen and "safe" signals are used.

Although the argument could be made that this was not designed to be set at
runtime, modules such as Perl::Unsafe::Signals are certainly doing that
already (just through XS and PL_signals):

http://cpansearch.perl.org/src/RGARCIA/Perl-Unsafe-Signals-0.02/Signals.xs

I have not evaluated this module specifically with 5.14, but its use does
not appear uncommon.

A quick scan through mg.c does not show anywhere that PL_signals is exposed,
unlike, say, $^H. Therefore there is no replacement in 5.14 for this lost
functionality.

I would like to request the old behaviour be reinstated for backward
compatibility.

Thanks for your consideration.

% perl514 -v

This is perl 5, version 14, subversion 0 (v5.14.0) built for darwin-2level

Copyright 1987-2011, Larry Wall
[...]

% perl514 -V
[...]
Summary of my perl5 (revision 5 version 14 subversion 0) configuration:

Platform:
osname=darwin, osvers=8.11.0, archname=darwin-2level
uname='darwin bruce.floodgap.com 8.11.0 darwin kernel version 8.11.0: wed oct 10 18:26:00 pdt 2007; root:xnu-792.24.17~1release_ppc power macintosh powerpc '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include',
optimize='-O3',
cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include'
ccversion='', gccversion='4.0.1 (Apple Computer, Inc. build 5370)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib -L/opt/local/lib'
libpth=/usr/local/lib /opt/local/lib /lib /usr/lib
libs=-lgdbm -ldbm -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib'

Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
Built under darwin
Compiled at Jun 5 2011 07:10:59
%ENV:
PERL_SIGNALS="unsafe"
@INC:
./lib
/opt/perl514/lib/site_perl/5.14.0/darwin-2level
/opt/perl514/lib/site_perl/5.14.0
/opt/perl514/lib/5.14.0/darwin-2level
/opt/perl514/lib/5.14.0
.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Nasty habits/Here to stay! -- Oingo Boingo ---------------------------------

[Leon Timmermans]

On Sun, Jun 5, 2011 at 6:50 PM, Cameron Kaiser
<perlbug-...@perl.org> wrote:
> Although the argument could be made that this was not designed to be set at
> runtime

Exactly. I'd personally call this a fix, not a bug.

> modules such as Perl::Unsafe::Signals are certainly doing that
> already (just through XS and PL_signals):

Is there any reason you can't use Perl::Unsafe::Signals instead? For
that matter, is there any reason you really have to use unsafe
signals? Really? It's a dangerous thing to do, and enabling it for the
entire duration of the program is really a bad idea.

> I would like to request the old behaviour be reinstated for backward
> compatibility.

I'd prefer a different solution to this. You can trivially write a
module on top of PUS that disables safe signal handling if you really
want that, no need for the ugly hack you're using right now:

package Perl::Unsafe::Signals::Global;
use Perl::Unsafe::Signals;
Perl::Unsafe::Signals::push_unsafe_flag();
1;

Leon

[Cameron Kaiser]

> > modules such as Perl::Unsafe::Signals are certainly doing that
> > already (just through XS and PL_signals):
>
> Is there any reason you can't use Perl::Unsafe::Signals instead? For
> that matter, is there any reason you really have to use unsafe
> signals? Really? It's a dangerous thing to do, and enabling it for the
> entire duration of the program is really a bad idea.

I imagine you would not consider this a good reason, but I specifically
support scripts that can run in environments where the only thing available
is the Perl binary (embedded systems and small installs particularly
benefit), and I have users who depend specifically on that functionality.
The previous behaviour worked fine in minimal environments; using P::U::S
would add, at best, an inconvenient dependency. Currently for 5.14 we are
using a workaround of a shell script that sets the variable and calls Perl,
which works, but is kludgey.

Rather than explain the whole of why I use unsafe signals, let me simply
say I am well aware of why they are considered "unsafe," but I do not find
Perl "safe signals" real-time enough for my purposes. I suspect others do
as well, which is why something like Perl::Unsafe::Signals exists in the
first place.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Even cabbage more sense than you! -- Shampoo, "Ranma 1/2" ------------------

[Leon Timmermans]

On Wed, Jun 15, 2011 at 6:23 AM, Cameron Kaiser <spe...@floodgap.com> wrote:
> Rather than explain the whole of why I use unsafe signals, let me simply
> say I am well aware of why they are considered "unsafe," but I do not find
> Perl "safe signals" real-time enough for my purposes. I suspect others do
> as well, which is why something like Perl::Unsafe::Signals exists in the
> first place.

Another possibility that doesn't require non-core modules is using
POSIX's sigaction() instead of %SIG to set the signal handlers. This
sets unsafe signal handlers by default (though you can chose per
signal if they should be safe or not).

Leon

[Cameron Kaiser]

> > Rather than explain the whole of why I use unsafe signals, let me simply
> > say I am well aware of why they are considered "unsafe," but I do not find
> > Perl "safe signals" real-time enough for my purposes. I suspect others do
> > as well, which is why something like Perl::Unsafe::Signals exists in the
> > first place.
>
> Another possibility that doesn't require non-core modules is using
> POSIX's sigaction() instead of %SIG to set the signal handlers. This
> sets unsafe signal handlers by default (though you can chose per
> signal if they should be safe or not).

I agree that would indeed be fine if the Perl standard library were present.
However, I do specifically support the situation where only the Perl bare
binary is present (the truly most minimal install of all), which like I say
is very useful to embedded systems. If this is no longer a supported
configuration to run Perl in, then I imagine we'll make do with the shell
script workaround and facultatively use POSIX.pm if it is present, though as
I say this is suboptimal for this particular purpose.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Bowl angry. ----------------------------------------------------------------

[Leon Timmermans]

On Thu, Jun 16, 2011 at 3:25 PM, Cameron Kaiser <spe...@floodgap.com> wrote:
> I agree that would indeed be fine if the Perl standard library were present.
> However, I do specifically support the situation where only the Perl bare
> binary is present (the truly most minimal install of all), which like I say
> is very useful to embedded systems. If this is no longer a supported
> configuration to run Perl in, then I imagine we'll make do with the shell
> script workaround and facultatively use POSIX.pm if it is present, though as
> I say this is suboptimal for this particular purpose.

If you're in control of the perl binary you could patch it to use
unsafe signals by default (see attachment), or you could try a
staticperl[1] approach to include POSIX.pm/Perl::Unsafe::Signals. If
not and POSIX is compiled in statically you can use it with a little
coercion.

Leon

[1]: http://search.cpan.org/perldoc?staticperl

[James E Keenan via RT]

On Fri Aug 26 22:57:53 2011, sprout wrote:

> On Sun Jun 05 09:50:25 2011, spe...@floodgap.com wrote:
> > A common idiom, at least in my code, is to have the script itself set
> > $ENV{'PERL_SIGNALS'} = "unsafe", such as in BEGIN { }, so that I don't
> > have
> > to pollute my environment with it ordinarily and the scripts that want
> > this
> > can set it themselves. This works fine in 5.8, 5.10 and 5.12. It does
> > not
> > work in 5.14; it requires that I already have the variable set before
> > the
> > script is executed, or the value is not seen and "safe" signals are
> > used.
> >

> > Although the argument could be made that this was not designed to be
> > set at

> > runtime, modules such as Perl::Unsafe::Signals are certainly doing

> > that
> > already (just through XS and PL_signals):
> >

> > http://cpansearch.perl.org/src/RGARCIA/Perl-Unsafe-Signals-
> > 0.02/Signals.xs

> >
> > I have not evaluated this module specifically with 5.14, but its use
> > does
> > not appear uncommon.
> >
> > A quick scan through mg.c does not show anywhere that PL_signals is
> > exposed,
> > unlike, say, $^H. Therefore there is no replacement in 5.14 for this
> > lost
> > functionality.
> >

> > I would like to request the old behaviour be reinstated for backward
> > compatibility.
> >

> > Thanks for your consideration.
>
> Looking at the signal-handling code in 5.12, I cannot see how this ever
> worked as you stated. But I could be misreading the code. If you could
> provide a test script to demonstrate the difference in behaviour, I
> could do a binary search and find out which commit it was.


The OP has not responded to Father C.'s question in more than two years.
Leon Timmermans was quite skeptical of the OP's request.

Is there any reason we should keep this ticket open?

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=92246

[Cameron Kaiser]

> > Looking at the signal-handling code in 5.12, I cannot see how this ever
> > worked as you stated. But I could be misreading the code. If you could
> > provide a test script to demonstrate the difference in behaviour, I
> > could do a binary search and find out which commit it was.
>
> The OP has not responded to Father C.'s question in more than two years.
> Leon Timmermans was quite skeptical of the OP's request.

I never received Leon's request. The difference in behaviour relates to
real-time signal handling; if a system call is running, it may not be
interrupted by a signal coming through. I could write up a script to bang
on a second process if you like to show the difference. The specific
application that went awry was TTYtter (and Texapp, its descendent) when
using a ReadLine driver; the ReadLine driver would send signals to TTYtter
to squelch it while the user was typing and only with 'unsafe' signals on
would the select() be reliably interrupted.

However, I suspect that there is no interest in restoring the prior
behaviour (as evidenced by this particular reply), so I've started requiring
users to either set this variable before starting the script, or have a full
installation with POSIX.pm. It's suboptimal, but it works.

I would be happy to try to fix this myself, if there is any interest in
accepting a patch.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- To generalize is to be an idiot. -- William Blake --------------------------

[Leon Timmermans]

On Sat, Sep 7, 2013 at 4:49 AM, Cameron Kaiser <spe...@floodgap.com> wrote:

I never received Leon's request. The difference in behaviour relates to
real-time signal handling; if a system call is running, it may not be
interrupted by a signal coming through. I could write up a script to bang
on a second process if you like to show the difference. The specific
application that went awry was TTYtter (and Texapp, its descendent) when
using a ReadLine driver; the ReadLine driver would send signals to TTYtter
to squelch it while the user was typing and only with 'unsafe' signals on
would the select() be reliably interrupted.

I can imagine running in such issues when using a XS module that don't respect Perl's signaling system, not in a pure-perl application (Which Texapp seems to be unless you've explicitly loaded Gnu Readline or some such).

So yes, I would be most interested in a *short* example of this problem, because this is either a bug in your code or in ours. Texapp is a 268kb, 7400SLOC script that doesn't even use strict. There's no way anyone is going to debug that.

 

However, I suspect that there is no interest in restoring the prior
behaviour (as evidenced by this particular reply), so I've started requiring
users to either set this variable before starting the script, or have a full
installation with POSIX.pm. It's suboptimal, but it works.

I would be happy to try to fix this myself, if there is any interest in
accepting a patch.

I don't think the old behavior should be restored, but one could argue the unsafeness should have been exposed using some magical variable.

Leon

[Cameron Kaiser]

> > I never received Leon's request. The difference in behaviour relates to
> > real-time signal handling; if a system call is running, it may not be
> > interrupted by a signal coming through. I could write up a script to bang
> > on a second process if you like to show the difference. The specific

> > application that went awry was TTYtter (and Texapp, its descendant) when

> > using a ReadLine driver; the ReadLine driver would send signals to TTYtter
> > to squelch it while the user was typing and only with 'unsafe' signals on
> > would the select() be reliably interrupted.
>
> I can imagine running in such issues when using a XS module that don't
> respect Perl's signaling system, not in a pure-perl application (Which
> Texapp seems to be unless you've explicitly loaded Gnu Readline or some
> such).

This related to Term::ReadLine::TTYtter, which is an altered version of
Term::ReadLine::Perl. This is pure-Perl, but does use Term::ReadKey, so I
don't know if that qualifies under "using an XS module." The signaling
is occuring Perl-to-Perl from a foreground process to a background process.

> So yes, I would be most interested in a *short* example of this problem,
> because this is either a bug in your code or in ours. Texapp is a 268kb,
> 7400SLOC script that doesn't even use strict. There's no way anyone is
> going to debug that.

As politely as I can put it, no expectation was made that you would. That said,

> > I would be happy to try to fix this myself, if there is any interest in
> > accepting a patch.
>
> I don't think the old behavior should be restored, but one could argue the
> unsafeness should have been exposed using some magical variable.

Would this be acceptable? It would seem more generally useful than the current
method, and would allow this kind of dynamic operation. Again, the fact that
modules exist as discussed above to allow this implies I'm not the only one
that would find dynamically changing this useful.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Apathetic dyslexic agnostic: "I don't care if there's a dog" ---------------