Re: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread Chris Withers
Paul Winkler wrote: I don't know what your intention is there, but fwiw, if what you're *really* interested in is the object being marked for deletion in the ZODB, you can use: I'm pretty sure that only works in Zope, so? the O.P. was about zope, and this IS the zope-dev list... Yup, but ZODB !=

Re: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread Mario Lorenz
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.

RE: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread 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? [Mario Lorenz] Yes, but when you push the minimize button, the cache target size is 0. That would do it wink. Nonwithstanding

Re: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread Toby Dickenson
On Tuesday 27 January 2004 19:08, Tim Peters wrote: Maybe Toby remembers which release(s) of ZODB the current cache implementation first appeared in Zope 2.6 -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED]

Re: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread Toby Dickenson
On Tuesday 27 January 2004 09:39, Mario Lorenz wrote: 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

Re: [Zope-dev] cPickleCache endless loop...

2004-01-26 Thread Toby Dickenson
On Friday 23 January 2004 17:08, Tim Peters wrote: It looks like ghostifying your self triggers self.__del__(). Then the __del__ method unghostifies self, which has the side effect of moving self to the MRU end of the ring, which in turn means the list traversal will visit self *again*.

Re: [Zope-dev] cPickleCache endless loop...

2004-01-26 Thread Paul Winkler
On Mon, Jan 26, 2004 at 08:59:36AM +, Chris Withers wrote: Paul Winkler wrote: On Fri, Jan 23, 2004 at 12:08:27PM -0500, Tim Peters wrote: def __del__(self): print About to destroy: , self.id I don't know what your intention is there, but fwiw, if what you're *really*

RE: [Zope-dev] cPickleCache endless loop...

2004-01-26 Thread Tim Peters
[Tim Peters] It looks like ghostifying your self triggers self.__del__(). Then the __del__ method unghostifies self, which has the side effect of moving self to the MRU end of the ring, which in turn means the list traversal will visit self *again*. When it does, same thing happens all over

Re: [Zope-dev] cPickleCache endless loop...

2004-01-26 Thread Toby Dickenson
On Monday 26 January 2004 17:22, Tim Peters wrote: 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, Right. That is more achievable than I thought. -- Toby Dickenson

Re: [Zope-dev] cPickleCache endless loop...

2004-01-25 Thread Dieter Maurer
Jeremy Hylton wrote at 2004-1-23 12:12 -0500: ... The only useful answer is to avoid using __del__ on persistent objects. If there are resources that really need to be finalized whenever the object is ghosted, you can put them in a non-persistent sub-object that does have an __del__. A minor

[Zope-dev] cPickleCache endless loop...

2004-01-23 Thread Mario Lorenz
Hello, we have spent most of the day tracking down obscure hangs of Zope (2.6.4rc1) under python2.1.3 on a RHEL3 machine. The problem seems to be a logic flaw somewhere related to the cPickleCache, when using a destructor in a Zope object that accesses itself. In our case(shortened to the

Re: [Zope-dev] cPickleCache endless loop...

2004-01-23 Thread Chris McDonough
Defining __del__ on a persistent object has unknown effects, FWIW. A persistent object's __del__ method may be called many times during its lifetime. See http://zope.org/Wikis/ZODB/FrontPage/guide/node3.html#SECTION00036 for more info. - C On Fri, 2004-01-23 at 09:55, Mario

RE: [Zope-dev] cPickleCache endless loop...

2004-01-23 Thread Tim Peters
[Mario Lorenz] we have spent most of the day tracking down obscure hangs of Zope (2.6.4rc1) under python2.1.3 on a RHEL3 machine. Based on what you say next, it sure sounds like this isn't unique to 2.6.4rc1. Did the same code work under some previous release? The infinite loop appears to be

Re: [Zope-dev] cPickleCache endless loop...

2004-01-23 Thread Jeremy Hylton
On Fri, 23 Jan 2004 10:31:59 -0500 Chris McDonough [EMAIL PROTECTED] wrote: Defining __del__ on a persistent object has unknown effects, FWIW. A persistent object's __del__ method may be called many times during its lifetime. See

Re: [Zope-dev] cPickleCache endless loop...

2004-01-23 Thread Paul Winkler
On Fri, Jan 23, 2004 at 12:08:27PM -0500, Tim Peters wrote: def __del__(self): print About to destroy: , self.id I don't know what your intention is there, but fwiw, if what you're *really* interested in is the object being marked for deletion in the ZODB, you can use: def