At 2:00 PM -0500 1/14/05, Thomas R Wyant_III wrote: >I tried :perlio, :stdio:crlf, :unix:crlf, and maybe others, but with $cmd >= "wait 00:00:30" and the timeout at 10 seconds, it universally took 30 >seconds to execute. Well, sometimes 31. But never 10.
Yup. That confirms you are definitely getting blocked by something. >$ assign "unsafe" PERL_SIGNALS > >did in fact restore the old behaviour. Not suprisingly, I can find no way >to do this from inside Perl. Even doing it in a BEGIN block didn't help. Yea, it's in perl.c even before it starts parsing your script. > > But we could have a >> bug or an implementation-defined behavior or a loophole closed for >> stability reasons but not documented properly. This would need to be >> tested and compared on various platforms before filing a bug report I >> think. > >I don't know whether by "various platforms" you mean other VMS-es on other >architectures or other OS-es completely. If the former, I'm a bit >challenged, since the system I'm reporting on (DEC C V5.6-003 on OpenVMS >Alpha V7.1-1H2) is the most modern one currently available to me (!). If >the latter I'm slightly better off, but not much: I just meant one or two other OSs. >With ActivePerl 810 (5.8.4) running under Win2000 and feeding it the >"pause" command, I get the same behaviour as under VMS, including the >results of "perl -V:useperlio". I have to hit return before the script >exits. Unlike 5.6.1, though, you _can_ use SIGALRM under Windows to time >out something like "sleep 1 until $timeout" (where $timeout is set by the >alarm handler). So we're closer, but still no cigar. > >Oddly enough, with Cygwin on the same machine as the ActivePerl 810 test >(Perl 5.8.6 this time) it works as advertised: 'sleep 30' with a 10-second >timeout completes in 10 seconds, using both :perlio and :stdio. I will >withhold the obvious editorial comment. > >I can check Darwin over the weekend, but after that I'll be pretty much >out of "various platforms" I can test personally. You've definitely proven it works differently on VMS. So lets look at what's going on a bit deeper. In mg.c, you can see in Perl_csighander and Perl_raise_signal what happens differently when unsafe signals are allowed and when they're not. When they're not, it just sets a flag that basically means "check me later." That check only happens when PERL_ASYNC_CHECK() is called, which is defined in perl.h like so: # define PERL_ASYNC_CHECK() if (PL_sig_pending) despatch_signals() The reason you're getting blocked must have something to do with our pipe implementation, which, since it's doing mailbox reads and writes via $QIOs, knows nothing about the Perl I/O layers. Those layers have PERL_ASYNC_CHECK() sprinkled all through them; whenever an I/O completes, it checks for pending signals. Fixing this may be as simple as putting PERL_ASYNC_CHECK() as the last line in each of the AST routines involved in pipe I/O in [.vms]vms.c. Then again, who knows what mayhem might result from doing this at AST level. I guess we won't know until we try, so I will see if I can work up a patch and get back to you. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
