killing thread ?
anton.wilson at camotion.com
Tue Feb 11 19:15:19 CET 2003
On Friday 24 January 2003 04:36 pm, Peter Hansen wrote:
> Uwe Schmitt wrote:
> > Uwe Schmitt <uwe.schmitt at procoders.net> wrote:
> > > But what if I want to end a thread which hangs because
> > > it uses 'exec' on some code which loops forever ?
> > so, what about a new PEP : extend the exec method by limiting
> > the execution time and memory usage ...
> I'd support a PEP that proposed being able to set a flag in
> a thread or in the interpreter so that a SystemExit exception
> would be thrown at the very next bytecode instruction that gets
> It's not foolproof, for those attempting to defeat it, and it
> still can't handle threads that are blocked in OS calls, but
> it works for many of the cases that people think they want it
> for, and it would suit me in all cases that I care about.
I'm somewhat interested in attempting to do this myself. You have any ideas
on how to communicate the kill message between threads? One way I can think
of right now is with a global list of threads to be killed that get's checked
in the interpreter loop. But then that adds one more global variable that is
protected by the global interpreter lock and more overhead to check the list
. . . See any other problems with this idea?
The way you suggested would, in a non-cross-platform manner, set up a
"A global signal handler then raises an exception in the
target thread which gets handled the usual way." I'm guessing that for this
to work, the thread that get's the signal would catch it in some imported c
module and then rasise the SystemExit exception from within the module.
Correct me if I'm wrong.
More information about the Python-list