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

Josiah Carlson josiah.carlson at gmail.com
Sat Jul 12 04:51:58 CEST 2008


This doesn't need to be an interpreter thing; it's easy to implement
by the user (I've done it about a dozen times using a single global
flag).  If you want it to be automatic, it's even possible to make it
happen automatically using sys.settrace() and friends (you can even
make it reasonably fast if you use a C callback).

 - Josiah

On Fri, Jul 11, 2008 at 4:27 AM, Andy Scott <kirkshorts at hotmail.co.uk> wrote:
> [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
>
>
> ________________________________
> Get Messenger on your Mobile! Get it now!
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com
>
>


More information about the Python-Dev mailing list