Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^2: Killing all processes launched using open()

by SmilingBuddha (Acolyte)
on Sep 17, 2004 at 03:30 UTC ( #391651=note: print w/replies, xml ) Need Help??

in reply to Re: Killing all processes launched using open()
in thread Killing all processes launched using open()

This is truly MAGICAL!! Thank you so much!!!

I must admit though that I'm still clueless as to why the lines under #child in run_shell() get executed if the routine returns before that in #parent. Or is it that run_shell() returns the hash and keeps executing until the end of the function?

Best regards,

  • Comment on Re^2: Killing all processes launched using open()

Replies are listed 'Best First'.
How the hidden magic does its stuff
by tmoertel (Chaplain) on Sep 17, 2004 at 05:05 UTC
    Glad I could be of assistance!

    Regarding your question, the magic occurs in the first line of run_shell. When open is called with "-|" as its file argument, it does something special: It forks the current process into two processes (parent and child) that run in parallel.

    The parent process is the same as the original process. It receives in $pid the child's process ID, and its $pipe variable contains a filehandle that can read from the STDOUT of the child process.

    The child process – and this is where it gets interesting – is running in parallel to the parent. The only difference is that in the child, the pid returned from open and stored in its copy of $pid is zero.

    So now we have the parent and the child running in parallel. The first thing they both do is check the value of $pid to figure out which is parent and which is child. If $pid non-zero, the one process then knows that it is the parent, and it can package up the information it received about the child from open and return the package to the original caller. If $pid is zero, the other process knows it is the child and then ties its STDOUT to STDERR, starts a new process group, and then uses exec to replace its own process image with that of the command we gave to run_shell as arguments.

    Thus, when run_shell returns, we have the following situation:

    • The original process has become a parent, and it continues running on the line after the call to run_shell. It holds in its variable $subshell the pid of its new child and a pipe to read output from the child. The parent also knows that there is a process group of the same ID as the child's pid, and that all of the child's descendants will belong to it.
    • The child process has now been taken over by the command that we wanted to be executed. The new command, however, is running in the environment that we set up earlier, while we had control of the child. Thus its STDERR is tied to its STDOUT, and it is running in a process group that the child set up and that the parent knows about.

    I hope that explanation clears things up.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2022-07-04 15:09 GMT
Find Nodes?
    Voting Booth?

    No recent polls found