in reply to Could "expect.pm for managing unreliable programs" help here?
in thread Test RegEx Validity
Perl used to be fragile in that signals arriving at inopportune moments could corrupt Perl's internal state. Now Perl postpones handling of signals until it's safe (between opcodes). This change may have surprising side effects because signals no longer interrupt Perl instantly. Perl will now first finish whatever it was doing, like finishing an internal operation (like sort()) or an external operation (like an I/O operation), and only then look at any arrived signals (and before starting the next operation). No more corrupt internal state since the current operation is always finished first, but the signal may take more time to get heard. Note that breaking out from potentially blocking operations should still work, though.The key sentence there is "Now Perl postpones handling of signals until it's safe (between opcodes).". Which means that any single opcode operation, such as a regexp match, can't be intterrupted by a signal. Which is what alarm is after all, it just tells the kernel to send a sigalrm after a certain amount of time. The effective point of all this is that alarm won't interrupt regexen that will run forever, if you are using a perl later than 5.8 (which you really should). Unless of course you're usingg perl 5.9. Which might or might not interrupt. But you probably shouldn't be using perl5.9, so thats a moot point.
|
|---|