How to get a raised exception from other thread

[Antoon Pardon]

Op 2005-10-17, Steve Holden schreef <steve at holdenweb.com>:
> 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,

Only in so far that correct programs behave correctly. The developers
are not obligated to correct buggy programs. They have every right to
say that if a programmor can handle certain concepts he should seek
help with that concept elsewhere.

> 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.

But the way it is made inaccessible has nothing to do with knowing
how to use the feature. That you can dable with C-extententions, pyrex
or ctypes says nothing about your ability to handle threads that
raise exceptions in each other.

>> 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.

What it there is no such convenient point? What if you have a number
of differnt routines that recursively call each other each with its
own number of nested loops. If you want something that is a bit
responsive you will have to put a check for this flag in any loop.

> 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."

IMO the flag is the better architecture in this case because python
can't interrupt a tread with an exception while that thread is in
C-code.

>> 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".

Then don't react to those questions. A lot of questions about threads
are already answered as follows: "Don't use threads", "use twised" or
"If you have to use threads, use Queues". IMO there is nothing wrong
with telling people that if they want to use certain features it is
expected they know what thet are doing.

> Asynchronous signalling between threads is an accident 
> waiting to happen in the hands of an inexperienced programmer.

So? Do we want python to be limited to features that can't
cause problems in the hands of an inexperienced programmer?

-- 
Antoon Pardon