From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 14 Feb 2008 20:14:37 +0000 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Google search of the day From: "Eris Discordia" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.23 (Win32) Topicbox-Message-UUID: 53efe4f6-ead3-11e9-9d60-3106f5b1d025 On Thu, 14 Feb 2008 17:28:03 -0000, Fco. J. Ballesteros 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 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 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/