[Zodb-checkins] CVS: ZODB3/Persistence - __init__.py:1.4.88.2 cPersistence.c:1.72.8.20 cPickleCache.c:1.85.8.8

[Jeremy Hylton]

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

Modified Files:
      Tag: zodb33-devel-branch
	__init__.py cPersistence.c cPickleCache.c 
Log Message:
Checkpoint of new cc_clear() code that causes gc assertion failures.


=== ZODB3/Persistence/__init__.py 1.4.88.1 => 1.4.88.2 ===
--- ZODB3/Persistence/__init__.py:1.4.88.1	Tue Jul  1 15:28:11 2003
+++ ZODB3/Persistence/__init__.py	Tue Jul  8 14:19:45 2003
@@ -14,3 +14,4 @@
 """Provide access to Persistent and PersistentMapping."""
 
 from cPersistence import Persistent
+from cPickleCache import PickleCache


=== ZODB3/Persistence/cPersistence.c 1.72.8.19 => 1.72.8.20 ===
--- ZODB3/Persistence/cPersistence.c:1.72.8.19	Tue Jul  8 10:43:06 2003
+++ ZODB3/Persistence/cPersistence.c	Tue Jul  8 14:19:45 2003
@@ -173,13 +173,13 @@
     if (self->state >= 0) 
 	ghostify(self);
     if (self->cache) {
-	/* XXX This function shouldn't be able to fail? If not, maybe
-	   it shouldn't set an exception either.
-	*/
-	/* Remove the object from the cache and DECREF self->cache */
-	if (cPersistenceCAPI->percachedel(self->cache, self->oid) < 0)
-	    PyErr_Clear(); /* I don't think this should ever happen */
+	/* XXX Not sure if it ever makes sense for this function to fail. */
+	assert(cPersistenceCAPI->percachedel(self->cache, self->oid) >= 0);
     }
+    /* If the object is being deallocated via GC, the percachedel call
+       will not release the object's reference to the cache.
+    */
+    Py_XDECREF(self->cache);
     Py_XDECREF(self->jar);
     Py_XDECREF(self->oid);
 }


=== ZODB3/Persistence/cPickleCache.c 1.85.8.7 => 1.85.8.8 ===
--- ZODB3/Persistence/cPickleCache.c:1.85.8.7	Tue Jul  8 10:42:29 2003
+++ ZODB3/Persistence/cPickleCache.c	Tue Jul  8 14:19:45 2003
@@ -619,18 +619,27 @@
     clear those out of the dict, too.  We accomplish that by replacing
     all the ghost objects with None.
 
-    Is it possible to deadlock if clear is called at a bad time? 
-
-    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.
+    We don't need to lock the ring, because the cache is unreachable.
+    It should be impossible for anyone to be modifying the cache.
     */
 
-    if (!lockgc(self, 0)) {
-	PyErr_WriteUnraisable((PyObject *)self);
-	return -1;
+    while (self->ring_home.next != &self->ring_home) {
+	CPersistentRing *here = self->ring_home.next;
+	cPersistentObject *o = OBJECT_FROM_RING(self, here, "cc_clear");
+	
+	if (o->cache) {
+	    Py_INCREF(o); /* account for uncounted reference */
+	    if (PyDict_DelItem(self->data, o->oid) < 0) 
+		return -1;
+	}
+	o->cache = NULL;
+	Py_DECREF(self);
+	self->ring_home.next = here->next;
+	o->ring.prev = NULL;
+	o->ring.next = NULL;
+	Py_DECREF(o);
+	here = here->next;
     }
-    assert(self->non_ghost_count == 0);
 
     Py_XDECREF(self->jar);
     Py_XDECREF(self->setklassstate);
@@ -916,7 +925,7 @@
 static PyTypeObject Cctype = {
     PyObject_HEAD_INIT(DEFERRED_ADDRESS(&PyType_Type))
     0,					/* ob_size */
-    "Persistence.cPickleCache",		/* tp_name */
+    "Persistence.PickleCache",		/* tp_name */
     sizeof(ccobject),			/* tp_basicsize */
     0,					/* tp_itemsize */
     (destructor)cc_dealloc,		/* tp_dealloc */