How to kill a thread?

[Antoon Pardon]

On 2008-06-10, Rhamphoryncus <rhamph at gmail.com> wrote:
> On Jun 10, 1:55 am, Antoon Pardon <apar... at forel.vub.ac.be> wrote:
>> On 2008-06-09, Rhamphoryncus <rha... at gmail.com> wrote:
>>
>>
>>
>> > On Jun 9, 5:33 am, Antoon Pardon <apar... at forel.vub.ac.be> wrote:
>> >> On 2008-06-07, Rhamphoryncus <rha... at gmail.com> wrote:
>>
>> >> > On Jun 6, 12:44 pm, The Pythonista <n... at this.time> wrote:
>> >> >> It's always been my understanding that you can't forcibly kill a thread
>> >> >> in Python (at least not in a portable way).  The best you can do is
>> >> >> politely ask it to die, IIRC.
>>
>> >> > Inherently, the best you can do in most languages is ask them politely
>> >> > to die.  Otherwise you'll leave locks and various other datastructures
>> >> > in an inconvenient state, which is too complex to handle correctly.
>> >> > The exception is certain functional languages, which aren't capable of
>> >> > having threads and complex state in the same sense.
>>
>> >> Well it would of course depend on what is considered asking politely?
>>
>> >> If one thread could cause an exception being thrown in an other thread,
>> >> would this be considered a polite way to ask? Would it be considered
>> >> an acceptable way?
>>
>> > The exception must not be raised until a point explicitly designed as
>> > safe is hit.  Otherwise, any function that manipulates data you'll
>> > still use will potentially be buggered.  Consider sys.stdout: codecs,
>> > buffering, lots to go wrong.
>>
>> I don't see the point. Exceptions are raised now without the ability
>> of an explicitly designed safe point. If something unexpected happens
>> your code can raise an exception and leave your data buggered too if
>> you didn't anticipate it propely.
>
> Although in theory you could get any exception at any point, in
> practise you shouldn't unless your program is broken.  If it is broken
> the exceptions shouldn't be caught and should cause the program to
> terminate, so the harm is reduced.  The exceptions that should happen
> (such as IOError) should be from predicted points, and anticipated.

In pratice you can schedule an alarm and have the alarm handler raise
an exception in your code. It is the resposibility of the developer to
write his code in such a way that it can handle such an interruption
as it should.

Given that the above is already possible I don't see why we should
protect the programmer from such an asynchronous exception merely
because they can be raised from an other thread.

-- 
Antoon Pardon