How to kill a thread?

[Fuzzyman]

On Jun 11, 8:41 pm, Rhamphoryncus <rha... at gmail.com> wrote:
> On Jun 11, 1:17 pm, Fuzzyman <fuzzy... at gmail.com> wrote:
>
>
>
> > On Jun 11, 6:49 pm, Rhamphoryncus <rha... at gmail.com> wrote:
> > > On Jun 11, 7:56 am, Fuzzyman <fuzzy... at gmail.com> wrote:
> > > > On Jun 11, 6:56 am, Rhamphoryncus <rha... at gmail.com> 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.

:-)

Michael