cswiger at mac.com
Sun Jun 1 21:15:08 CEST 2003
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
...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
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. :-)
More information about the Python-list