Defensive programming

[Chuck Swiger]

Jack Diederich wrote:
[ ... ]
>> All the operating system can do is kill the runaway process; how is
>> that acceptable for multiple client processes?
>
> Not very!  But the OS could send a catchable signal that means 'knock it off.'
> The default behavior would be to kill the process, but the program could
> redefine it if there is a smart way to cleanup & die.

Unix and POSIX platforms support the notion of process resource limits and will 
send SIGXCPU to a process that exceeds the amount of CPU time it's allowed:

      SIGXCPU         terminate process       cpu time limit exceeded (see
                                              setrlimit(2))

...and, as Jack suggests, a process could register it's own handler instead of 
SIGDFL via signal() to clean up first.  Another notion that's not tied to a 
specific platform involves keeping track of how many transactions a given 
process has serviced, and having it exit after a while-- ie, the 
"MaxRequestsPerChild" directive to Apache.

[ ... ]
> CPU/memory quota policies would have to be explicitly defined by the
> admin for particular programs & services.  The guys over on linux-kernel
> have tried lots of heuristics to intelligently kill world-eating memory hogs
> but all the heuristics fail in one way or another (killing init is a popular
> misstep).

Oh, goodness.  Well, people try to sleep() in the kernel as well; there is a 
certain charm to seeing someone happily advocate a triangular wheel because it 
has one less bump per revolution than a square wheel does.  :-)

-- 
-Chuck