"Craig A. Berry" <[EMAIL PROTECTED]> wrote on 01/14/2005 09:32:40 AM:
<snip /> > Surely you want > my $pid = open ($pipe, "$cmd|") or die; Absolutely right. I noticed this later, but the posting had already lain fallow for a bit, and I decided to correct myself when I gave a progress report, if nobody caught it sooner. > Configured to use perlio or stdio? Try The PERLIO environment variable is not defined on the system, and I haven't put any "use open" pragmas in the script. The actual "open" is accounted for. The perlipc doc says this means :perlio for 5.8.4, but it also seems to say that I should get my signals delivered if :perlio is in use. Or am I reading it wrong? Perlrun says the default is :stdio, but I guess I would expect perlipc to rule in this case. > $ define PERL_SIGNALS "unsafe" Since the code fragment in question is part of a Perl module, I think I'll play around with I/O disciplines before defining the environment variable. > and see if that makes any difference. I have a feeling that what > you're running into is that Perl signals since 5.7.3 are deferred in > order to avoid interrupting things that shouldn't be interrupted. You > can read up on the whole safe signals thing here: > <http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals- > (Safe-Signals)> Thanks for the reference. I could swear that I looked at perlipc before posting (as well as perlport and perlvms), but I was certainly blind to this. Because the code in question can potentially be used any time 7 x 24, I have band-aided it by spawning two subprocesses: the one being timed out and a Perl one-liner that sleeps for the desired time, posts an INT to the parent (to signal the timeout), and a KILL to the victim. Maybe INT was the wrong signal, but I was in a hurry. Thank you very much for the response, Tom Wyant This communication is for use by the intended recipient and contains information that may be privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html