[Pdx-pm] to fork or thread...
kyle at silverbeach.net
Sun Sep 21 14:36:38 CDT 2003
On Sunday 21 September 2003 10:57, Chris Dawson wrote:
> 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.
More information about the Pdx-pm-list