Re: Re: Fork and zombies

Waynn Lue wrote: >> >> Yeah, that's what I ended up doing, and defining some global >> variables so that I could re-use the previous functions I created, >> thanks for the help! >> >> One other question I had, is pcntl_waitpid necessary in this case? >> Passing WNOHANG to it causes it to return immediately regardless of >> whether the child has exited or not, and my previous test when I >> didn't use pcntl_waitpid seemed to not leave any zombies as well. >> Would it be fine just to spawn off the child, and have the child exit >> at the end, and continue on my merry way with the parent without >> checking the status of the child? Unless you do the wait or waitpid once per child, I'm pretty certain you'll end up with a few zombies. >> As a more general question, I'm worried that if I just keep the >> script as is, it's going to spawn off some crazy number of processes >> if I don't cap it. I would definitely put a limit on it - you may also have limits imposed by your database and any other resources the children share. >> The first solution I came up with is to use a static variable in >> the parent thread, and then sleep every 20 threads or so. The most >> robust solution would be to build logic into the calling function to >> actually check for pids and only dispatch new threads when old ones >> had finished, but that requires changing multiple places, while this >> can be localised to just the dispatcher function. Does the first >> solution I propose seem sane? I think it is best done in the dispatcher. I have such a setup in at least one place - I've set a max of 4 jobs, and I simply increment the counter at fork() and decrement when wait() returns a pid. /Per -- Per Jessen, Zürich (6.8°C)