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.
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]
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
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*.
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*
[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
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
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
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
[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
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
11 matches
Mail list logo
