Nevermind.  I see what Toby did in the signals module and it makes
sense.

On Wed, 2002-11-13 at 11:01, Chris McDonough wrote:
> Maybe normal shutdown should manually call the shutdown signal handler
> function and normal restart should manually call the restart signal
> handler function?  
> 
> On Wed, 2002-11-13 at 10:28, Toby Dickenson wrote:
> > On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote:
> > > >>>>> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes:
> > >     >> This is a bad thing for the Berkeley storages because their
> > >     >> .close() must get called or you'll end up with corrupt
> > >     >> databases or worse <wink>.
> > >
> > >     TD> How much of that paragraph is covered by the wink?
> > >
> > > The "or worse" part.  If you've enable autopacking and you don't
> > > cleanly close the storage, you won't exit the process because the
> > > autopack thread won't get stopped and joined.
> > 
> > Yes, I had the same problem with DirectoryStorage, which uses a seperate 
> > thread to move writes from its journal directory into the database directory. 
> > 
> > >  We could make the
> > > autopack thread a daemon process
> > 
> > Thats how DirectoryStorage now works.
> > 
> > > It wouldn't be good, but remember that we run BerkeleyDB in
> > > auto-recovery mode, so it means that the next time you open the
> > > database, it will run recovery (you can also run recovery manually).
> > > However, depending on your checkpointing policy, and the size of
> > > committed data since your last checkpoint, recovery could end up
> > > taking a long time.
> > 
> > Last time I looked at your BerkeleyDB storages, the administrator needed to 
> > implement his own checkpointing policy. I always thought that was a 
> > disadvantage. Would it now be a good idea for the storages to trigger their 
> > own checkpointing inside the autopacker thread?
> > 
> > > Sure, any number of bad things can happen at any time, and defense
> > > against that is one of the benefits of using BerkeleyDB underneath.
> > > But under normal operations, we definitely want to exit cleanly.
> > 
> > Agreed, on both points.
> > 
> > 
> > 
> > _______________________________________________
> > Zope-Dev maillist  -  [EMAIL PROTECTED]
> > http://lists.zope.org/mailman/listinfo/zope-dev
> > **  No cross posts or HTML encoding!  **
> > (Related lists - 
> >  http://lists.zope.org/mailman/listinfo/zope-announce
> >  http://lists.zope.org/mailman/listinfo/zope )
> 
> 
> 
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )



_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to