[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/_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
