[Python-Dev] A proposed solution for Issue 502236: Asyncrhonous exceptions between threads

[Andy Scott]

[OK so a newbie post here so many apologies if I am doing this wrong]
Quick Synopsis:
 
 A child thread in an executing Python program can not safely shutdown the program. The issue URL is: http://bugs.python.org/issue502236
 
So my proposal is:
 
Example:
 
  We have three threads -
        t0 - Main system thread
        t1 - Worker thread
        t2 - Worker thread
 
  t1 encounters an issue that means it wants to shut down the application in as safe a way as possible
 
 
A Solution:
 
 1. Put in place a new function call sys.exitapplication, what this would do is:
     a. Mark a flag in t0's data structure saying a request to shutdown has been made
     b. Raise a new exception, SystemShuttingDown, in t1.
 2. As the main interpreter executes it checks the "shutting down flag" in the per thread data and follows one of two paths:
    If it is t0:
     a. Stops execution of the current code sequence
     b. Iterates over all extant threads setting the "system shutdown" flag in the per thread data structure. Setting this flag is a one time deal - it can not be undone once set. (And to avoid issues with multiple threads setting it - it can only ever be a single fixed value so setting it multiple times results in the same answer)
     c. Enters a timed wait loop where it will allow the other threads time to see the signal. It will iterate this loop a set number of times to avoid being blocked on any given thread.
     d. When all threads have exited, or been forcefully closed, raise the SystemShuttingDown exception
 
    If it is not t0:
     a. Stops execution of the current code sequence
     b. Raises the exception, SystemShuttingDown.
 
There are problems with this approach, as I see it they are (but please see the assumptions I have made):
 
P1. If the thread is in a tight loop will it see the exception? Or more generally: when should the exception be raised?
P2. When should the interpreter check this flag?
 
I think the answer to both of these problems is to:
 
 Check the flag, and hence raise the exception, in the following circumstances:
 
  - When the interpreter executes a back loop. So this should catch the jump back to the top of a "while True:" loop
  - Just before the interpreter makes a call to a hooked in non-Python system function, e.g. file I/O, networking &c.
 
 Checking at these points should be the minimal required, I think, to ensure that a given thread can not ignore the exception. It may be possible, or even required, to perform the check every time a Python function call is made.
 
I think this approach would then allow for the finally handlers to be called.
 
Assumptions:
 
[Here I must admit to a large amount of ignorance of the internals of Python at this time. So if my assumptions are incorrect I would greatly appreciate being told so :-) Preferably as polite as possible and any code pointers while welcome unless they point to some very esoteric and arcane area would be best kept general so I feel more of a spur to go learn the code base]
 
 1. The Python interpreter has per thread information.
 2. The Python interpreter can tell if the system, t0, thread is running.
 3. The Python engine has (or can easily obtain) a list of all threads it created.
 4. It is possible to raise exceptions as the byte code is executing.
 
I am mailing this out as:
 
 A. I have no idea if my thoughts are correct or total un-mitigated rubbish :-)
 B. I believe the introduction of this proposal (if I am correct) will require a PEP being raised, which aiui requires building community support (which is very fair imo) so this is me trying to do so :-)
 
So apologies if this post has been total spam (but no eggs) or too long - give a little whistle and it will all be OK again.
 
Andy
--------------------------------------Brain chemistry is not just for Christmas
_________________________________________________________________
Play and win great prizes with Live Search and Kung Fu Panda
http://clk.atdmt.com/UKM/go/101719966/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080711/2e69e93e/attachment.htm>