How to kill a thread?

[Fuzzyman]

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:
> > > So how does .NET deal with the sys.stdout corruption?  Does it?
>
> > That has never been an issue for us.
>
> Of course.  It's far more likely to hit the underlying blocked I/O
> than the buffer management, unless it's doing a great deal of I/O.  Or
> alternatively, they're using some other mechanism to prevent
> interruption during buffer management.
>
>
>
> > > If you've carefully written your code to use only safe primitives and
> > > local state (discarded if interrupted) then yes, it could be
> > > interruptible.  At this point you could specially mark that block of
> > > code as safe, leaving the vast majority of other code unsafe by
> > > default.  Then again, since you're going to the trouble of carefully
> > > designing and auditing your code you could just make it cancellable
> > > like blocking I/O should be - just by polling a flag at key points
> > > (and you're CPU-bound anyway, so it's not expensive.)
>
> > > The only place I know of that you *need* arbitrary interruption is
> > > hitting CTRL-C in the interactive interpreter.  At this point it's a
> > > debugging tool though, so the risk of weirdness is acceptable.
>
> > We use background threads for long running calculations that we know
> > are safe to abort. Resources that need protecting we do with finally
> > blocks which the thread abort honours.
>
> 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:
    ...



> > 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. :-)


Michael Foord
http://www.ironpythoninaction.com/