develooper Front page | perl.perl5.porters | Postings from September 2013

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

Thread Previous | Thread Next
From:
Cameron Kaiser
Date:
September 11, 2013 04:52
Subject:
Re: [perl #92246] Perl 5.14 does not allow "internal" setting of $ENV{'PERL_SIGNALS'}
Message ID:
201309110153.r8B1rn0G13959320@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" ---------------

Thread Previous | Thread Next


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