Re: background system() and stillalive() sub

I am curious to learn more about this application.
Unfortunately I don't have a *nix system to test on right now although I often have several (some rebuilds of my environment are in progress).

With unix you can start multiple processes "in the background".
$> program_a 1 2 &
$> program_a 3 4 &

A Unix process started in this way runs at a lower priority than the process that started it. Also I think, if you die, they die also. This is different than a detached separate process which will keep running even if you die. A process like that can even have a higher priority than the process that launched it.

You can scan the pid table (ps command) to see if program_a is still running. What is the need to determine which instance of program_a is running? Does it really matter if you can identify that the instance of program_a which was called with parms 1 2 vs 3 4 is running? Maybe not? Maybe so?

If Perl can't deliver the PID of a new process, you can scan process table and then re-scan to see the new PID that shows up when Perl says "hey", system command worked".

Comment on Re: background system() and stillalive() sub

Replies are listed 'Best First'.
Re^2: background system() and stillalive() sub by cdarke (Prior) on Aug 02, 2009 at 12:36 UTC
if you die, they die also When the parent process ends it sends a SIGHUP to child processes. That will not kill child processes if they ignore or handle the signal. That can be done in a number of ways, but from perl: `$SIG{'HUP'}='IGNORE';`. If you do this in the parent then child processes inherit DEFAULT or IGNORE signals in the signal mask (not handlers). There are several reason why the pid might be required, waitpid or kill spring to mind. See the modules mentioned above, or write your own based on fork.	[reply] [d/l]
Re^3: background system() and stillalive() sub by Marshall (Canon) on Aug 02, 2009 at 13:09 UTC
Handling a signal with something that says "I'm explicitly ignoring this signal" is different than not handling (or not dealing with) the signal at all. Basically these signals like SIGINT, will terminate you if you don't have a plan to deal with it. Yes, you can override the default behavior, but I don't think that is what the OP is asking about.	[reply]