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
Cameron Kaiser
September 10, 2013 06:14
Re: [perl #92246] Perl 5.14 does not allow "internal" setting of $ENV{'PERL_SIGNALS'}
Message ID:
> > 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 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: --
  Cameron Kaiser * Floodgap Systems * *
-- To generalize is to be an idiot. -- William Blake --------------------------

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About