On 1039345745 seconds since the Beginning of the UNIX epoch
Jaromir Dolecek wrote:
>

>> It is true that you could hack thttpd to avoid this happening, but it
>> is only the easiest example of why the idea is bad, it is hardly the
>> only one. In general, I don't want my processes to block unless they
>> ask to, period -- it screws up everything from userland threads
>> packages to all event driven servers.
>
>All event driven servers which fork unbounded number of children,
>and depend on the OS limits to force the runaway application to
>behave, that is.
>
>If the fork() fails, the app would error out and wouldn't be able
>to do anything useful anyway.

Um, only in the serving of that one CGI script.  Yes, this is the
case.  So what?  What else is it going to do if it runs into its
own internal limit?  Break the limit?  Fail?  To make the point a
bit more obvious, consider this tiny code fragment which satisfies
your requirement that thttpd count its children:

int	numchildren=0;

int
myfork()
{

	if (++numchildren < maxchildren)
		return fork();
	else
		return -1;
}

and presume that the wait calls decrement numchildren, of course.

Then how exactly would that be different from the current situation?

Sure, you'd never get tslept for .5s, now, but what other actual
change would it make?  It does satisfy your concern that the program
in question does not keep track of outstanding children, though.
Oh, hold on.  This actually does _not_ guarantee that you will not
be tslept for .5s, see below.

It would make exactly no difference in thttpd's actual behaviour
over using the OS resource limits and hence would be a waste of
code.  So why do it?

>My opinion is  that if you frequently bump into your limits during
>normal operation, the system is not configured properly.

But, actually the above code does not count the number of outstanding
children.  Or at least it only counts the outstanding children, it
makes no effort to count the outstanding grandchildren or
great-grandchildren all of whom are going to be used by the OS
resource limitation code to determine if the fork(2) is allowed.
So, you are still in a situation where the event-driven server may
be stopped in its tracks for a seeming eternity because it bumps
into a resource limit.

>I don't consider thttpd as valid example. If it's serving CGI (the
>only time when it forks, besides directory index), it's trivially
>DoSable and thus totally unsuitable for any public server.

This argument appears on the face of it to be a cop-out.  There
are many publicly accessible servers in basesrc and pkgsrc that do
not count outstanding children.

I'm not even convinced that Apache is not vulnerable to running
into its resource limits, because it doesn't keep track of how many
children I am spawing in CGI-scripts.  Apache's model is substantially
more complex that thttpd's, so I'd have to look a bit closer into
the code to hazard a guess as to its behaviour.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/