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 <tdickenson@geminidataloggers.com> 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 - Zope-Dev@zope.org 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 )