Am 26. Jan 2004, um 12:22:43 schrieb Tim Peters: > It's actually that the number of __del__-resurrecting objects *plus* the > number of non-ghostifiable objects in cache is larger than the cache target > size, right?
Yes, but when you push the minimize button, the cache target size is 0. Nonwithstanding our code (it was mostly debugging/tracing functionality anyway, so it was easy to fix), it is just that with Zope 2.5, it seemed to work (at least I never got a bug report back then) so it took us a while to track this down. Especially since we had just moved to RHEL3, so we were expecting more like a threading issue... Given that this property is not that widely published (in the various tutorials etc.), I wonder if it might be a good idea to improve that loop check code, and walk through the ring not more than once, using a counter, and not the comparison vs. the ring start, which, as we have seen, may be a target that moves too quickly. > Similarly <wink>, except that if there's a large number of non-ghostifiable > objects (more than the cache target size), then only one __del__-resurrected > object is enough to provoke an infinite loop. Yes, this is exactly what happened here. Mario -- Mario Lorenz EMail: [EMAIL PROTECTED] Tel: 03774 6625-78 Technik Netze Handy: 0160 3151600 km3 teledienst GmbH Fax: 03774 6625-79 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )