[Python-Dev] (os.kill (was Fork) on Win32 - was (test_fork1
failing...)
M.-A. Lemburg
mal@lemburg.com
Thu, 03 Aug 2000 15:40:05 +0200
Mark Hammond wrote:
>
> eek - a bit quick off the mark here ;-]
>
> > Signals are a bit of a problem on Windows. We can terminate the thread
> > mid-execution, but a clean way of terminating a thread isn't obvious.
>
> thread = process - you get the idea!
>
> > terminate-without-prejudice option any good?
>
> really should say
>
> > terminate-without-prejudice only version any good?
Well for one you can use signals for many other things than
just terminating a process (e.g. to have it reload its configuration
files). That's why os.kill() allows you to specify a signal.
The usual way of terminating a process on Unix from the outside
is to send it a SIGTERM (and if that doesn't work a SIGKILL).
I use this strategy a lot to control runaway client processes
and safely shut them down:
On Unix you can install a signal
handler in the Python program which then translates the SIGTERM
signal into a normal Python exception. Sending the signal then
causes the same as e.g. hitting Ctrl-C in a program: an
exception is raised asynchronously, but it can be handled
properly by the Python exception clauses to enable safe
shutdown of the process.
For background: the client processes in my application server
can execute arbitrary Python scripts written by users, i.e.
potentially buggy code which could effectively hose the server.
To control this, I use client processes which do the actual
exec code and watch them using a watchdog process. If the processes
don't return anything useful within a certain timeout limit,
the watchdog process sends them a SIGTERM and restarts a new
client.
Threads would not support this type of strategy, so I'm looking
for something similar on Windows, Win2k to be more specific.
Thanks,
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/