sending thread exceptions (was Re: RELEASED Python 2.3.1)

[Peter Hansen]

Alex Martelli wrote:
> 
> I and Just canvassed widely at Europython, looking for people to
> suggest more use cases, and nobody came up with anything that stood
> up to examination beyond our basic use case of "debugging possibly
> buggy (nonterminating) code, in cases where we just can't run the
> possibly buggy code in the main thread and delegate a separate
> watchdog thread to the purpose of interrupting the main one" 

[snip Peter's example]

> Yes, yet another subcase of that one and only use case we kept
> coming up with (just like my own immediate application for the
> feature, and Just's, were two other such subcases).  If you can
> come up with use cases that are NOT just restatements of this
> one with fake beards, now THAT would be interesting (and might
> perhaps see the functionality exposed in module threading in
> Python 2.4:-).  

I know this won't meet the standard, but what about a use case
involving "actually running (as opposed to debugging) possibly 
buggy (non-terminating) code".  This could come up in cases such as
our embedded Linux product, which is supposed to be a long-running
process.  

And yes, to make it clear, I am actually suggesting the possibility
that the product could ship with buggy code that could cause that
condition.  It does happen in the real world... more often than 
anybody normally cares to admit.  More often with multi-threaded
applications than is good for anyone, of course.  Sometimes,
nevertheless, an ugly necessity.  Especially when custom digital
hardware is involved, as with embedded systems, and one can't
possibly test for all potential configurations or conditions.

The alternative to attempting to terminate the offending
thread, then restarting it, would be to kill the entire process, 
which has a much more severe and immediate impact in several ways.
For example, startup of the application is on the order of 22 
seconds, and during that time the user sees no response, so a 
restart is definitely a last resort.

It would be "nice" to have the option of attempting to terminate
just the offending thread (based on an internal watchdog feature
which detected the bad condition) and then restart it, allowing the
rest of the application to continue largely unimpeded and not
affecting the user experience as severely.  (To tie this closer
to the actual case: the user can still access the system through
a serial port, but network communications, which is all but 
invisible to the user in this case, might halt briefly as the thread
restarted.)

Yes, I'm reaching somewhat.  Although I actually would like that
feature, even if it were available it would be quite some time 
before implementing it would be high enough on the list of priorities
to bother.  And wait!  It _is_ available, just not directly, so I 
can hardly complain. :-)

Point mostly taken...

-Peter