Perry E. Metzger wrote:
> I don't want my processes, especially non-blocking ones, to
> mysteriously get involuntary stutters in their execution when they hit
> an error condition. Roland mentioned, for example, what will happen to
> a web server in a crisis if your idea is left in -- a bad situation

I've seen mention of thttpd. thttpd indeed spawns uncontrolled
number of children. As a crude clue stick, the sleep induced on
the main thttpd process gives the children time to finish serving
the content, exit and actually create more breathing room to serve
more content. BTW, thttpd spawns separate process even
for serving static content AFAIK (at least it did during my
benchmark, I don't use thttpd otherwise).
I don't see how leaving main thread busy loop in fork() would help
anything.

Apache has configuration options MinSpareServer, MaxSpareServers.
Apache never attempts to spawn more children than MaxSpareServers.

> (cgi overload) goes worse (even static content is no longer delivered
> in a timely manner and the number of open connections
> soars). Similarly, see what would happen to several classes of SMTP

You are not telling me that SMTP servers generally spawn
uncontrolled number of chilren, are you?

AFAICS sendmail has MaxDaemonChildren option, which seems to default
to 12.  Postfix has default_process_limit, which is 50 in
/usr/share/examples/postfix/sample-resource.cf.

> Blocking processes arbitrary uncontrolable amounts of
> time during error conditions is VERY VERY BAD.

In general case, I agree with this.

However, this particular error condition is pretty much in
administrator's hands. If system daemons hit the limits frequently
during normal operation, admin didn't configure system properly.

The change helps tremendously for real time-sharing
multiuser machines. I do still remember my years on university,
where stuff like this was frequent problem, since students
actually learned unix programming and made the fork() mistake
quite often (I did it couple of times too). The induced sleep
turns this frequent problem to nonissue.

If the main problem of the change is the 'uncontrollable' aspect,
it's easy enough to add sysctl to control how long is the
process hibernated when it hits the limit. But I maintain it's
useful to have some reasonably long sleep time as default.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-