Front page | perl.perl5.porters |
Postings from September 2013
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. LeonThread Previous