From spectre@floodgap.com

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 * ckaiser@​floodgap.com
-- Nasty habits/Here to stay! -- Oingo Boingo ---------------------------------

From @Leont

On Sun, Jun 5, 2011 at 6​:50 PM, Cameron Kaiser
<perlbug-followup@​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

The RT System itself - Status changed from 'new' to 'open'

From spectre@floodgap.com

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 * ckaiser@​floodgap.com
-- Even cabbage more sense than you! -- Shampoo, "Ranma 1/2" ------------------

From @Leont

On Wed, Jun 15, 2011 at 6​:23 AM, Cameron Kaiser <spectre@​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

From spectre@floodgap.com

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 * ckaiser@​floodgap.com
-- Bowl angry. ----------------------------------------------------------------

From @Leont

On Thu, Jun 16, 2011 at 3​:25 PM, Cameron Kaiser <spectre@​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

From @Leont

diff --git a/perl.c b/perl.c
index 417b2fd..2e0bda9 100644
--- a/perl.c
+++ b/perl.c
@@ -2166,6 +2166,9 @@ S_parse_body(pTHX_ char **env, XSINIT_t xsinit)
 	 else
 	      Perl_croak(aTHX_ "PERL_SIGNALS illegal: \"%s\"", s);
     }
+    else {
+	PL_signals |= PERL_SIGNALS_UNSAFE_FLAG;
+    }
     }
 
 #ifdef PERL_MAD

From @cpansprout

On Sun Jun 05 09​:50​:25 2011, spectre@​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.

From @jkeenan

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

On Sun Jun 05 09​:50​:25 2011, spectre@​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

From @Leont

On Sat, Sep 7, 2013 at 4​:49 AM, Cameron Kaiser <spectre@​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

From spectre@floodgap.com

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 * ckaiser@​floodgap.com
-- Apathetic dyslexic agnostic​: "I don't care if there's a dog" ---------------