Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Re: The 'ol shell timeout question

by xiper (Friar)
on Jun 18, 2003 at 03:55 UTC ( #266719=note: print w/replies, xml ) Need Help??

in reply to Re: The 'ol shell timeout question
in thread The 'ol shell timeout question

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: Re: Re: The 'ol shell timeout question
by Anonymous Monk on Jun 18, 2003 at 04:30 UTC


    As for the link, it's perl pod, perldoc perlipc!!! Normally I wouldn't yell, but I see monks giving answers all the time, and then I see the monk who asked for help simply ignoring half of what was said.

    edited: Wed Jun 18 15:22:25 2003 by jeffa - turned volume down (s/h1/h3/g)

Re: Re: Re: The 'ol shell timeout question
by bluto (Curate) on Jun 18, 2003 at 16:25 UTC
    The sad fact is that I've never seen an easy bulletproof implementation of timing out system/qx/backticks or the equivalent fork/exec implementation, especially if you want to grab output. This topic is more complex than just slapping in an alarm call, and I don't see how the other suggestion to use Sys::AlarmCall makes any difference (since it appears to time out functions).

    Your code looks ok to me, but when it times out, you'll need to kill and reap the child with something like this...

    if ($@) { kill $your_favorite_sig, $pid; waitpid($pid, 0); } else { .... }
    Otherwise the child can keep running indefinitely, or if it does die at some point it will be a zombie.

    The most straightforward way of capturing output is to send it to a file and then read the file after the command completes (i.e. use ">tmp_file" as part of your exec). This is a hack, but it is easy and more importantly generally safer than the simpleminded "open a pipe, read the pipe, interrupt the read with an alarm" alternative. The problem with this is it assumes that interrupting the read with a SIGALARM is always safe. It may theoretically be on all platforms (hopefully yours), but I'm not convinced. Also, what does perl do if the alarm occurs and it happens to be filling in and perhaps reallocating the read in buffer?

    Since I don't want to depend on knowing and I'm generally paranoid when it comes to signals, I'd expect the program to crash occasionally. If you can handle the crashes, great. If you are like me and don't want to, you have to resort to timing out the individual reads (see the IO::Select "can_read" method), take the easy road of using a separate file, or check out Dominus's answer to my first question to PerlMonks about this topic for another solution.

    • Please read the question... Sys::AlarmCall has nothing to do with either killing/preventing zombies, or capturing output.
    • I've read perlipc already!! Sheesh...

      Thanks for the helpful info and link (and *reading* my question :) ). When so many things in perl are easy to do, one expects everything to be easy - my mistake. I think i have enough to go on now to have a play around.

      - ><iper

      my JAPH: print"Just another Perl hacker\n"; # ^ look, no space! pretty tricky hey?

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://266719]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2023-01-27 13:56 GMT
Find Nodes?
    Voting Booth?

    No recent polls found