[Pdx-pm] to fork or thread...

[Kyle Hayes]

On Sunday 21 September 2003 10:57, Chris Dawson wrote:
> Hello,
>
> I am trying to write a SOAP client/server program.  I want to start
> another program inside my start() method, and then stop that program
> using the stop() method.  I am unsure as to how I should execute the
> child program, and then what I should do to stop it.  I have been
> experimenting with fork, but I don't know the proper way to kill the
> child process.  I am happy to use perl 5.8 and the threads module if
> necessary, but I am not clear on whether I should signal the external
> application, kill it using it's pid, or what.  Any suggestions?  This is
> all happening in a linux environment, so that should simplify things.  I
> have tried writing a script which upon the stop() method, runs a
> 'killall program_name' but this appears to leave a bunch of zombie
> processes, which is not optimal.  They don't get cleaned/reaped until
> the program is shutdown completely, and I want to have this running
> non-stop for a while.  I don't think the zombies are an issue and are
> not consuming resources, but I think there must be a limit to the number
> of child processes associated with an application, correct?

Child processes will persist as zombies until the parent process gets the 
process termination code.  So, you need to have a call to waitpid somewhere 
or that within a SIGCHLD signal handler.  I am assuming that you are on some 
form of Unix-like OS.  I have no idea if any of this is useful for Windows.

'perldoc -f waitpid' is your friend.

I usually put a waitpid inside a while loop inside the SIGCHLD handler.  Seems 
like overkill, but two or more child processes can die before you get into 
the SIGCHLD handler so you need to check the return status for all of them.

You need to set up a signal handler for SIGCHLD.  Be aware that there are some 
tricky race conditions to having a parent program monitor child programs.  I 
would suggest looking at Net::Server and similar modules.  It is harder than 
you'd think to get this stuff right in a lot of cases.

Best,
Kyle