> in case that a process failed in getting resource such as memory or process,
> what it should do is very limited: puts out some message and exits.
> this is right behavior.
practically, for most simple programs fork error is handled by sysfatal().
but things get more tricky for libthread programs like rio.
from thread(2):
Errors, notes and resources
Thread library functions do not return on failure; if errors
occur, the entire program is aborted.
in your simple forkloop case, the kernel can break the loop by failing the fork
there
but if at the same time you draw a window or hit interrupt key while the system
ran out of processes, the proccreate() in rio can render your window system
unusable.
and what about stuff like your multithreaded filservers? factotum? cs? dns?
plumber?
note that there are interdependencies betweeen these... and there might be
multiple instances running (multiple users on a cpu server).
the point is, you need to take on the effort of hardening *all* the long
running and
forking servers against this so they can recover from failing fork, or else you
have nothing gained compared to what the kernel does currently.
could be done, but its hard to get right and test if you got it right.
i'd go for giving the students ther own terminals so they crash ther own
machines
instead of taking down cpu servers :)
--
cinap
