How to kill a thread?

[Rhamphoryncus]

On Jun 11, 7:56 am, Fuzzyman <fuzzy... at gmail.com> wrote:
> On Jun 11, 6:56 am, Rhamphoryncus <rha... at gmail.com> wrote:
>
>
>
> > On Jun 10, 3:41 pm, Fuzzyman <fuzzy... at gmail.com> wrote:
>
> > > On Jun 10, 2:03 am, Rhamphoryncus <rha... at gmail.com> wrote:
>
> > How does that protect code like this?
>
> > f = open('somefile', 'w')
> > # interruption here
> > try:
> >     ...
> > finally:
> >     ...
>
> How does it *not* protect you if you write this instead:
>
> f = None
> try:
>   f = open('somefile', 'w')
>   ...
> finally:
>   if f is not None:
>     ...

Yeah, that should be safe, so long as the open call itself is
protected.


> > > The calculation is 'coarse grained' (it can call into .NET APIs that
> > > can take a relatively long time to return) - so polling for exit
> > > wouldn't work anyway. We also run user code and can't expect their
> > > code to poll for exit conditions.
>
> > Do those .NET get interrupted at arbitrary points?  Is this
> > "untrusted" user code also audited for correctness?  (Although I'd bet
> > you simply document what you do and blame the user if something
> > breaks.)
>
> We don't audit our user code - of course. We do document and assist
> them as necessary. Changing to a more restrictive model still wouldn't
> meet our use case and put *more* of a burden on our users.
>
> Our situation is not the only one. In general there are situations
> where you may want to put a long running calulcation on a background
> thread and you *know* that it is safe to interrupt - but Python
> currently won't let you.
>
> > 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. ;)

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.

I think what bothers me is, even if those external APIs support polite
cancellation properly, your forced interruptions will bleed over and
mess them up.  There needs to be a way of containing it better.
Writing them in another language (as C is used for most of Python's
builtins today) isn't a reasonable requirement.