Bill Studenmund wrote:
> Well, that seems like part of the problem. You have a view of what is
> proper behavior, and part of that seems to be that running into the
> process limit is punishable; if you're running into the limit, you're
> mis-behaving.

Yes, this more or less my view.
 
Definitely process running into it's limits is more suitable for
punishment than random other process. I believe that the limits
are supposed to be set so that the users/system are able to do
their work, but still catch runaway cases.  So if the limit _is_
reached, it's IMHO fine to use drastic measures.

There is some prior art, even. During out-of-memory condition,
processes asking for more memory are killed.  Processes not asking
for more memory can continue running happily.  Similarily CPU
limits, process is terminated if it reaches the limit.

Process slots are not that scarce. The limit for number of
processes is reached very seldomly. When it _is_ reached, it
is very likely that Something isn't behaving properly; either
there is some Unexpected Load, DoS going on, silly mistake
of local user, or something is misconfigured. In all these
cases, the induced sleep helps administrator to get things under
control more easily.

There are no mysterious failures caused by the sleep. If the
out-of-slots condition passes, all system activity goes to normal
shortly. If the out-of-slots condition continues, the processes
most likely causing trouble (those forking) are punished. Maybe
it's not quite ideal behaviour, but it's quite a good approximation
and has zero overhead cost.

> Saying a program is, "broken," because it uses what was a perfectly
> legitimate programming method before, though, seems judgemental.
>
> I think it's perfectly fine to fork until you can't. The kernel has to
> keep track of your process limit, and can politely tell you you've hit it.
> Why duplicate that in userland? Also, by doing that, if the kernel limit
> is ever changed, you immediately can take advantage of it.

Yes, I think it's perfectly fine to do that as well. Just don't
expect to do that AND get the resources immediatelly all the time.
If real-time response is expected, there is no other option than
pre-allocate (pre-fork, in this case), and more carefully control
how many resources are consumed.

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.''     -=-