[Python-3000] threading, part 2

[Slawomir Nowaczyk]

On Thu, 10 Aug 2006 23:01:45 -0400
Luis P Caamano <lcaamano at gmail.com> wrote:

#> Yes, I also wonder about how non-CPython implementations would handle
#> this but I'd just like to say that this feature, making a thread raise
#> a specific exception from another thread asynchronously is a very
#> useful feature.
#> 
#> We have a subsystem that schedules requests that are dispatched in a
#> thread each.  The only way to cancel one of those requests right now
#> is via a cooperative checking method in which we explicitly make calls
#> through out the code to see if the request has been canceled, and in
#> such case, the check raises an exception that triggers clean up and
#> cancellation.
#> 
#> Problem is we have to spread check calls all over the place.  All this
#> would be a lot easier if we could do thread.terminate() as proposed,
#> especially for new code.

"All over the place"? Literally? In other words, how likely is it that
your code would still be correct if you had this check after *every*
single statement? Or even more often -- every N bytecodes?

I believe that if asynchronous exception raising ever gets officially
approved, there absolutely *needs* to be a way to block it for a piece
of code that should execute atomically.

It is (more or less) OK to have an unofficial way to terminate the
thread, with "use on your own risk", because there are situations
where it is useful and (in a cooperative environment) reasonably safe
thing to do. 

But it should not be done lightly and never when the code is not
specifically expecting it.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk at cs.lth.se )

Live in the past and future only.