On Dec 19, 2003, at 8:55 AM, Dan Anderson wrote: [..]
I'm creating an app that uses forks in a number of places to do things
quicker. Unfortunately, I have a bad habit of accidentally fork bombing
my box.
I'm not sure I get this phrase 'fork bombing' to begin with, do you mean that you wind up forking more processes till you over run the kernel's process table and then things start dying off in 'un-natural states'? Or that you forgot to do appropriate thing with managing your SIG_CHLD so that you are not over running the kernel's process table with a bunch of zombie processes that could be harvested?
cf perldoc perlipc
Is there any way I can run a perl process (even if it's a Linux command) so that it wont eat up all available resources if I screw up? Or do I just need to learn to be more careful?
Actually, no. If your linux boxes is rigged to have various limits set, then there are some ways to prevent a given process/user from over-running more than that limit. But if one writes bad code, there is almost nothing that perl can do to protect you from your code.
What you may want to think about is rigging your code to have a '$max_child' and that the parent will wait on any new forks until that value is decremented.
In like manner, the 'child process' so forked, would be limited to either
a. not Forking any children
b. no more than ($max_child - 1) number of children
then the problem is mostly factorial...You might also strategize with say semaphours so that all of the processes would be able to deal with getting a common head count - but that way also leads to weirdneff as to who keeps the write on the semaphours...
You could also try to limit some of your madness by doing a pipe and fork, as you will might possibly bump into the FD limit before you 'fork bomb' your box. In this strategy the parent has some chance of being the negotiator of what is going on...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
