How to get a raised exception from other thread

[Steve Holden]

Antoon Pardon wrote:
> Op 2005-10-17, Alex Martelli schreef <aleaxit at yahoo.com>:
> 
>><themightydoyle at gmail.com> wrote:
>>
>>
>>>Nevermind.  I found a better solution.  I used shared memory to create
>>>a keep-alive flag.  I then use the select function with a specified
>>>timeout, and recheck the keep-alive flag after each timeout.
>>
>>Definitely a better architecture.  Anyway, one supported way for a
>>thread to raise an exception in a different thread is function
>>thread.interrupt_main(), which raises a KeyboardInterrupt in the *main*
>>thread (the one thread that's running at the beginning of your program).
>>
>>There's also a supported, documented function to raise any given
>>exception in any existing thread, but it's deliberately NOT directly
>>exposed to Python code -- you need a few lines of  C-coded extension (or
>>pyrex, ctypes, etc, etc) to get at the functionality.  This small but
>>non-null amount of "attrition" was deliberately put there to avoid
>>casual overuse of a facility intended only to help in very peculiar
>>cases (essentially in debuggers &c, where the thread's code may be buggy
>>and fail to check a keep-alive flag correctly...!-).
> 
> 
> I find this rather arrogant. It is not up to the developers of python
> to decide how the users of python will use the language. If someone
> has use of specific functionality he shouldn't be stopped because his
> use is outside the intentions of the developers.
> 
The developers have to support (at no cost) what the users do, so if 
they want to make use of certain features inaccessible to users who are 
likely to go wrong then that's up to them.

> Just suppose you are writing a chess program. You let the program
> "think" while it is the users move, but this thinking has to be
> interrupted and some cleanup has to be made after the users move
> has made a lot of this thinking obsolete by his move. Such code
> could be mixture of loops and recursion that makes use of a simple
> flag to end it all, unpractical. Use of an exception raised from
> somewhere else would IMO in this case be an acceptable choice.
> 
In *your* opinion, possibly. In my opinion it would seem to make more 
sense to have the worker thread code examine a shared flag and raise an 
exception at some convenient point in its calculation cycle. Otherwise 
you have to write the worker thread to be capable of handling 
asynchronous signals, which is a notoriously difficult task. I presume 
this is why Alex commented that he thought the OP's "better solution" 
was "definitely a better architecture."

> Why should the coder of this software have to go through this
> deliberate set up attrition, to get at this functionality, just
> because it wasn't intented to be used in such a way by the
> developers?
> 
Because otherwise people who know no better will use the feature for 
purposes where it's not the best way to achieve the required 
functionality, leading to yet more endless discussions about why "it 
doesn't work". Asynchronous signalling between threads is an accident 
waiting to happen in the hands of an inexperienced programmer.

> As far as I know, pyrex and ctypes weren't intended to get
> at the Python/C api. But they didn't create extra hurdles
> for those who could use it that way.
> 
This seems like a complete non sequitur to me. Let's stick to the point.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/