The Artima Developer Community
Sponsored Link

Python Buzz Forum
One note on Python simplicity in handling phoenix problems

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Dmitry Dvoinikov

Posts: 253
Nickname: targeted
Registered: Mar, 2006

Dmitry Dvoinikov is a software developer who believes that common sense is the best design guide
One note on Python simplicity in handling phoenix problems Posted: Apr 23, 2006 1:56 AM
Reply to this message Reply

This post originated from an RSS feed registered with Python Buzz by Dmitry Dvoinikov.
Original Post: One note on Python simplicity in handling phoenix problems
Feed Title: Things That Require Further Thinking
Feed URL: http://www.pythomnic.org:8000/atom2rss
Feed Description: The postings here are mostly random assorted thoughts on software development. As suggested by the blog title they almost always require further elaboration.
Latest Python Buzz Posts
Latest Python Buzz Posts by Dmitry Dvoinikov
Latest Posts From Things That Require Further Thinking

Advertisement
One of the major problems in developing long running applications (and applications in general really) is cleanly handling shutdown. Among them a particular subproblem of phoenix singletons - what happens sometimes if one entity references the other (typically a global singleton), which has already been unloaded.

For instance, consider the following shutdown code in moduleA (using simplified Python syntax):

moduleA:
...
def shutdown():
moduleB.callme()
there is no guarantee that moduleB has not been shut down yet. Now, if moduleB is also written in a delayed initialization fashion, ex:

moduleB:
...
impl = Impl()
...
def callme():
if not impl.initialized():
impl.initialize()
return impl.callme()
...
def shutdown():
impl.cleanup()
then what happens upon moduleA's shutdown is a reinitialization of the impl - one sort of a phoenix. It just went on me that instead of building a complex synchronization schemes to handle this cleanly, all I need to do to prevent this is just

moduleB:
...
def shutdown():
impl.cleanup()
del impl
and now as impl is just not there, the moduleA's attempt to reference it at shutdown will fail and throw - a much more appropriate behaviour in a given situation. This is less clean a solution, but how simple it is !

Read: One note on Python simplicity in handling phoenix problems

Topic: Python 3000 Slides Previous Topic   Next Topic Topic: php fsockopen woe

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use