but just denying the fork will also stop the fork bomb. 
sure, itll use a lot of cpu. an admin can come by and kill them off, 
though. the delay wont do anything that cant be done already, and adds 
unneeded complexty and special cases into the mix. one would have to 
check for this particular case (and keep state to check for it) on every 
fork (or keep even more state to reduce the times one would need to check).
if the quota on user processes is enforced, and a superuser can get 
reserved slots to do what he needs, then he can stop and kill off the 
offending suspects anyway. a daemon could also check for these conditions 
from userland and, if it ran as root, do the stopping and killing too.

isildur

On Wed, 4 Dec 2002, Phil Nelson wrote:

>  On Wednesday, December 4, 2002 at 10:07:35 (+0100), Jaromir Dolecek wrote:
> 
> > Subject: Fork bomb protection patch
> >
> > * make process sleep for 0.5s if the system table is full
> >   or when the user reaches their process number limit
> >   - this is to not hog the system with huge number of CPU-hungry
> >     looping processes
> 
> How about having this .5s sleep kick in only after a user has had 
> a number of unsuccessful forks without a successful one.  This would still
> stop the fork bomb, but let non-bombs that run at the process limit continue
> without the .5s sleep.
> 
> --Phil
>