Interrput a thread

[John Nagle]

On 1/4/2011 6:11 PM, Adam Skutt wrote:
> On Jan 4, 10:12 am, Fuzzyman<fuzzy... at gmail.com>  wrote:
>>
>> This is a case that .NET (C#) handles better than Python or Java.
>>
>
> Nope, read the documentation for Thread.Abort() carefully.
> Thread.Abort() can cause termination inside a static constructor,
> which is very bad.  You sure your application can cope with that?
> Mine can't.  Thread.Abort() is only safe for self-abortion, app domain
> termination and a few other very narrow and obscure scenarios.  It is
> not a safe way to end arbitrary threads doing arbitrary processing.
>
>> It's another place where people
>> sometimes have a genuine need/use case yet people will insist on
>> telling them they don't *really* want it...
>>
>
> Because there's no safe way to do it.  It's fundamentally a racy
> operation, with the typical horrible consequences when you lose.
> Removing the race requires support from the application, i.e., you
> have to write the code yourself.  Frequently, it's simply not possible
> to remove the race.

     There are systems where there's support designed in for thread
abort.  LISP/Scheme systems tend to support it.  QNX, the real-time
OS, has well worked out thread-abort semantics at the C level.
(QNX has really good features for "not getting stuck", like the
ability to put a time limit on any system call.)
But Python doesn't support things like that.

     What you'd really like in Python is the ability for one thread
to be able to force an exception in another thread, plus a
mechanism for locking out such exceptions for critical sections.
It's not worth having, though, in a system where you can really only
run one thread at a time.

				John Nagle