How to kill a thread?

Rhamphoryncus rhamph at
Wed Jun 11 21:41:27 CEST 2008

On Jun 11, 1:17 pm, Fuzzyman <fuzzy... at> wrote:
> On Jun 11, 6:49 pm, Rhamphoryncus <rha... at> wrote:
> > On Jun 11, 7:56 am, Fuzzyman <fuzzy... at> wrote:
> > > On Jun 11, 6:56 am, Rhamphoryncus <rha... at> wrote:
> > > > I'm not saying it can't be made to work in your specific case - it
> > > > likely does work well for you.  I'm saying it can't work *in
> > > > general*.  Stretching it out for general use turns those little cracks
> > > > into massive canyons.  A language needs a general mechanism that does
> > > > work - such as a polite cancellation API.
> > > Neither *works in general* - polite cancellation *doesn't* work for
> > > our us. That's my point - you probably want *both* for different use
> > > cases. :-)
> > Yeah, but mine's less icky. ;)
> But requires more code. :-)

Both require significant support from the implementation, and you're
not the one volunteering to write it (I am).  Besides, they're
complementary, so we should have both anyway.  The question is how
best to fit them together.

> > I think the ideal for you would be a separate process.  I'd also
> > suggest a restricted VM only in a thread, but that probably wouldn't
> > work for those long-running .NET APIs.  Now, if those long-
> > running .NET APIs did polite cancellation, then you could combine that
> > with a restricted VM to get what you need.
> No - we need to pull a large object graph *out* of the calculation
> (with no guarantee that it is even serializable) and the overhead for
> marshalling that puts using multiple processes out of the running.

Ouch.  So if it fails you want it isolated and killed, but if it
succeeds you want to share it with the rest of the program.

> What we *want* is what we've got! And it works very well... None of
> the problems you predict. :-)

Which points to an unknown mechanism protecting the vulnerable code,
such as using a different language.

I think we've run out of material to discuss.  We're about 80% in
agreement, with a 20% disagreement on philosophy.

More information about the Python-list mailing list