On Thu, 14 Feb 2008 17:28:03 -0000, Fco. J. Ballesteros <[EMAIL PROTECTED]>
wrote:
Children die soon in that one. This one is worse,
even the child starts spawning and so on...
while(1) fork();
I mistook your reference in the book and copy-pasted the code for the more
benign runaway process.
And, thanks for having written the book and made it available online. I
could not have begun learning Plan 9 without your book.
On Thu, 14 Feb 2008 17:51:59 -0000, Iruata Souza <[EMAIL PROTECTED]>
wrote:
not if the pids are randomized as in OpenBSD.
Did not know that. On FreeBSD it seems like the pids tend to grow as the
number of processes grows. Had someone known the highest pid before the
runaway process was executed, they could have killed any process with a
higher pid.
On Thu, 14 Feb 2008 17:27:19 -0000, erik quanstrom <[EMAIL PROTECTED]>
wrote:
i don't see an easy systematic solution to this type of problem.
Some sort of rate control? Say, at most 5 processes per second. Of course,
that would also interfere with a busy webserver that spawns worker
threads/child processes for new connections. That could be solved by
running the webserver as a user belonging to the legitimately busy class.
Perhaps the question is, "what, other than human discretion,
differentiates a runaway process from a normal albeit busy one?" There is
very little evidence to distinguish a loop striving to compute the largest
prime number from a loop computing the factorial of 1234567890, an
altogether more useless task :-)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
