<DIV>Glyph,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You hit the nail square on on both points.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. Things happen. In reviewing bsddb, I find that its gennerally </DIV>
<DIV>recommended to run recover as part of the startup process.</DIV>
<DIV>This makes clean shutdowns a bit less critical. But still, I'm</DIV>
<DIV>thinking it should be attempted.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Sometimes services need to be shut down without taking down</DIV>
<DIV>Twisted. This is especially important if Twisted is also going to</DIV>
<DIV>provide an administration interface, as some administration activities</DIV>
<DIV>may be easier when the base service is off-line.</DIV>
<DIV>&nbsp;</DIV>
<DIV>3. Support of non-critical service failure? A service may sometimes be</DIV>
<DIV>critical and othertimes not. Sounds like a configuration issue that</DIV>
<DIV>would be nice to standardize at some point. But perhaps the best</DIV>
<DIV>solution would be to leave it up to something else, perhaps a service</DIV>
<DIV>monitor service, which can decide when its not worth keeping Twisted</DIV>
<DIV>running, or perhaps putting it into a "I'm dead except for administration</DIV>
<DIV>services" mode.</DIV>
<DIV>&nbsp;</DIV>
<DIV>One conclusion here is that perhaps a service should never say die</DIV>
<DIV>(er, stop). Its always better to separate a smart service from the smarts</DIV>
<DIV>needed to manage that service--a service should&nbsp;rarely be coupled to the</DIV>
<DIV>management logic.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bill<BR><BR><B><I>Glyph Lefkowitz &lt;glyph@divmod.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Fri, 2004-05-21 at 20:47, Bill la Forge wrote:<BR><BR>&gt; If I write a generic service, even a MultiService, for use in multiple<BR>&gt; applications (as is my intent), then there is still a possibility that<BR>&gt; some other service, specific to a particular application, or an<BR>&gt; unrelated <BR>&gt; generic service, may fail to initialize. So the need to capture the <BR>&gt; shutdown event remins.<BR><BR>Bill,<BR><BR>I appreciate your questions on these shutdown issues, since I think we<BR>do still have a few semantic issues to nail down regarding startup and<BR>shutdown. However, I do think it's worth mentioning that you should<BR>never depend too heavily on shutdown code if you are interested in<BR>reliability: servers do crash, and machines do lose power, so a "clean"<BR>shutdown should always be a convenience and not a necessity.<BR><BR>(A more serious issue that we need
 to address is making sure that you<BR>can _attempt_ to bring up a new service inside an already running<BR>reactor, fail to bring it up, and not interrupt existing,<BR>already-running services or alter their state in some way; or, that you<BR>can bring it up and bring it down with the same results.)<BR><BR><BR>_______________________________________________<BR>Twisted-Python mailing list<BR>Twisted-Python@twistedmatrix.com<BR>http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</BLOCKQUOTE><BR><BR>Bill la Forge<br>http://www.geocities.com/laforge49/<p><font face=arial size=-1>
<a href="http://in.rd.yahoo.com/specials/mailtg/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">
<b>Yahoo! India Matrimony</a>:</b> Find your partner 
<a href="http://in.rd.yahoo.com/specials/mailtg2/*http://yahoo.shaadi.com/india-matrimony/community.php" target="_blank">online</a>.</font>