Because I want the children currently in-process to complete naturally, rather than being terminated before completing. (This also assumes that there will not be a failure which kills them, which could happen, but would be outside my control at that point.)
| [reply] |
Hmmm, that doesn't really follow.
set_max_procs controls how many processes $pm->start() will "create" at once; it has nothing to do with killing running processes (or not).
Since you're doing a wait_all_children, they will complete naturally. set_max_procs won't have any effect either way (I think).
Can you try your test without it? Your test program kills my NT box running cygwin completely, so it's a multi-purpose app :)
--
Mike
| [reply] |
You speak truthfully regarding $pm->start(), as I am beginning to understand it. As I am currently understanding it (which may still be in error), it appears that routine basically enqueues them by looping thru, performing a non-blocking wait for a child process to terminate while there are more than the maximum number of processes waiting, then proceeds to where it can launch the next one if that maximum number is non-zero.
I want those processes still operating when the alarm occurs to continue naturally if it was only because of the timeout. When that is the cause of the alarm, I reset the maximum number of processes to 0 because a that point I didn't want additional processes to launch, only my current ones to complete.
I haven't tried that test under Windows/cygwin yet, but plan to try, although if the code works and my logic is sound, it will most likely run on a *nix box of some kind. My appreciation also for the responses, because they are being quite helpful.
| [reply] |