On 20/03/15 09:37, Peter Otten wrote:
def close_relay(e=None,v=None,t=None):
try:
if not relay_closed()
really_close_relay()
except:
really_close_relay()
The purpose of the if clause is to ensure that
if the function is called many times you only
close the relay once (I surmised that more than
once could be harmful?)
import sys, atexit
atexit.register(close_relay)
sys.excepthook = close_relay
atexit should be overkill, but it might be needed
if for some reason the interpreter dies while
performing the usual cleanup.
excepthook replaces the usual exception mechanism
with a clean up. This is needed for cases where an
exception occurs before getting to the finally. We
want to close the relay ASAP, not waiting till
the interpreter decides to call the finally.
try:
main program here
finally:
close_relay()
This is the happy path where everything shuts down as expected.
That reeks of cargo cult. Are there actual scenarios for each of the three
mechanisms where it is the only one that works?
In real-time you never trust anything.
Always cover your back.
I would expect that
try:
main program here
finally:
close_relay()
provides the same level of confidence,
Only if the interpreter is behaving as normal.
The hooks are to try (we hope) to catch cases where
the interpreter has broken its normal flow.
So the scenarios are:
1) an unexpected exception occurs - close the relay ASAP.
- Use excepthook
2) The interpreter gets sent a kill or similar unexpected
termination - use atexit because finally may not get
called. (I'm not sure, so belt n' braces here)
(BTW Does anyone know what the interpreter does when
suspending - Ctrl-Z in Unix land?)
3) Normal program exit. Use the finally clause.
But its only ever going to be a best endeavour, that's
why Python is not suitable for true real-time/critical apps...
But I'd never trust any environment to its usual behaviour
if there is a possibility of something being broken.
In this case the relay and its battery pack.
the program closes normally or the main code raises an exception, but not if
the process is killed.
What's not clear in the Python documentation is how Python responds
to a kill(or suspend). I'd hope the atexit got called even in a kill.
I would not expect the finally to be executed.
Of course, if its a seg fault you are probably stuffed either way...
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
