Firstly, you've changed your OP without indicating what you've changed. Please do not do this! It's perfectly OK to edit your nodes but do ensure you clearly mark what you've changed: "How do I change/delete my post?" explains the how and why of this.

"About the 'exit' statement, I have a 'next' in the parent's 'if' statement, so only the child reaches the 'exit'."

The exit statement is still not clearly bound to the child code. The exit statement is still in the subroutine definition. Is there a reason you do not wish to use return.

"The potential 'while' infinite loop - is there a better way to wait for the number of child processes to drop below the max?"

I've already suggested using sleep and alarm. Do you have a problem with that suggestion? If so, what is it?

Hi Ken,

Sorry for the late reply. I did add a 'sleep 1' statement in the while loop. Everything seems to be working fine now. I had taken a perl class at a community college, and I literally got the if/else statement, with the exit, from the instructor's example code. Should I put a 'return' in the child's else loop?

Thanks,

Rachel

Using return was a suggestion.

I wrote:

Having said that, I recommend you read what exit says about exiting from subroutines. Even if the simple fix I described above works for you now, when you next add a little more "complexiy" you may find yourself with problems again. Perhaps you could return with the child PID instead of using exit; then, if the end of &multi_dir is reached, return with zero — that way, you can test the return value of multi_dir() and exit if it's the child or continue with the main script if it's the parent. Here's an example:

Assuming you read the exit doco, you now need to make a decision about whether any of the reasons for not using exit in a subroutine apply to you.

• If none apply, do nothing.
• Otherwise, pick an appropriate alternative:
  • die — discussed in the exit doco
  • POSIX::_exit($status) — discussed in the exit doco
  • return — which I suggested: it takes the subroutine out of the equation; example code supplied
  • or something else of your own devising.

-- Ken