[ On Sunday, December 8, 2002 at 21:51:01 (+0100), Jaromir Dolecek wrote: ]
> Subject: Re: Fork bomb protection patch (Was: Re: CVS commit: syssrc/sys/kern)
>
> OTOH, it still seems to be not right that thttpd would spawn
> potentially unbound number of children with no way to control
> the number besides resource limits.

Why do you think that is wrong?  There's always a bound on the number of
processes that can be run, regardless of what actual resource
availability enforces the limit.  An administrator is free to use
whatever resources his system has available in whatever way seems most
appropriate for the application.  Allowing thttpd to spawn children
until fork() fails is a perfectly legitimate way to allow a given system
configuration to serve the maximum possible number of HTTP clients --
i.e. get the most bang for your buck.

Did you not read the thttpd manual and documentation as well as it's
sources?

It is designed very explicitly to work _with_ operating system limits,
including file descriptors:

       you can control the overall number of connections for the whole
   server very simply, by setting the operating system's per-process
   file descriptor limit before starting thttpd.  Be sure to set the hard
   limit, not the soft limit.

A system that cannot be pushed to its limit and still continue operating
at 100% maximum potential throughput is broken.

Why do you continue to insist on duplicating complexity in all the wrong
places?

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>