[Zodb-checkins] CVS: ZODB3/Persistence - cPersistence.c:1.72.8.18 cPickleCache.c:1.85.8.7

[Jeremy Hylton]

Update of /cvs-repository/ZODB3/Persistence
In directory cvs.zope.org:/tmp/cvs-serv11400/Persistence

Modified Files:
      Tag: zodb33-devel-branch
	cPersistence.c cPickleCache.c 
Log Message:
Extend and revise comments.


=== ZODB3/Persistence/cPersistence.c 1.72.8.17 => 1.72.8.18 ===
--- ZODB3/Persistence/cPersistence.c:1.72.8.17	Tue Jul  8 09:54:43 2003
+++ ZODB3/Persistence/cPersistence.c	Tue Jul  8 10:42:28 2003
@@ -402,24 +402,23 @@
   {NULL,		NULL}		/* sentinel */
 };
 
+/* The Persistent base type provides a traverse function, but not a 
+   clear function.  An instance of a Persistent subclass will have
+   its dict cleared through subtype_clear().
+
+   There is always a cycle between a persistent object and its cache.
+   When the cycle becomes unreachable, the clear function for the 
+   cache will break the cycle.  Thus, the persistent object need not
+   have a clear function.  It would be complex to write a clear function
+   for the objects, if we needed one, because of the reference count
+   tricks done by the cache.
+*/
+
 static void
 Per_dealloc(cPersistentObject *self)
 {
     deallocated(self);
     self->ob_type->tp_free(self);
-}
-
-static int
-Per_clear(cPersistentObject *self)
-{
-    /* Don't do anything!
-
-    Any cycle involving a persistent object must also involve the cache.
-    If we clear the object now, the ghostify() code will fail to remove
-    it from the cache.  The cache's tp_clear slot will ghostify this
-    object, so that should be safe.
-    */
-    return 0;
 }
 
 static int


=== ZODB3/Persistence/cPickleCache.c 1.85.8.6 => 1.85.8.7 ===
--- ZODB3/Persistence/cPickleCache.c:1.85.8.6	Tue Jul  8 10:36:05 2003
+++ ZODB3/Persistence/cPickleCache.c	Tue Jul  8 10:42:29 2003
@@ -618,14 +618,14 @@
     not safe to decref the dict until it's empty, so we need to manually
     clear those out of the dict, too.  We accomplish that by replacing
     all the ghost objects with None.
-    */
 
-    /* XXX Is it possible to deadlock if clear is called at a bad time? 
+    Is it possible to deadlock if clear is called at a bad time? 
 
-    Yes.  When lockgc() executes, it is possible to cause enough
-    excess allocations to trigger a gc.  So we need a better solution.
-    
+    In theory, scan_gc_items() could cause garbage collection to occur,
+    but it seems impossible that scan_gc_items() would be operating
+    on a cache that was also unreachable.
     */
+
     if (!lockgc(self, 0)) {
 	PyErr_WriteUnraisable((PyObject *)self);
 	return -1;