How to kill a thread?

[Rhamphoryncus]

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


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

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.