On Friday January 11 2008 12:30:05 pm Andi Vajda wrote:
> On Fri, 11 Jan 2008, Pete wrote:
> > Ok, so if I have some code that manages the lifespan of a Lucene builtin
> > OR Python extension (we're all duck-typers here), how is it supposed to
> > know whether to call finalize or not?
> >
> > Though, hmm, if I'm reading correctly, I could just do:
> >
> > try:
> > lucene_or_python_obj.finalize()
> > except AttributeError:
> > pass # must have been a pure lucene object
> >
> > I guess that's ok. Though it'd be really nice if you found a solution to
> > automagically manage things without the explicit finalize()... weakrefs
> > maybe?
>
> Did you look at test/test_PythonDirectory.py ?
Yes.
> In there you can see that the way it's done is by keeping track of the
> python extension instances being allocated. Java never allocates these, you
> do, so you can keep track of these objects and finalize() them "at some
> point" of your choice.
Perhaps you're not understanding me... I've got code that looks more or less
like:
class DoesThingsWithSearcher(object):
def __init__(self, factory):
self.searcher=factory() # who knows/cares what we get here,
# as long as it has the right interface
def alldone(self):
self.searcher.close()
try:
self.searcher.finalize()
except AttributeError:
pass # must have been a Lucene object, not a python extension
Yes, in this case, a Python searcher should have called finalize() in it's
close() (which should probably be considered 'best practice' anyway), but if
the object doesn't *have* a close(), there's no good answer. Just calling
finalize() and catching AttributeError seems to be appropriate. Not a big
deal.
> Yes, of course, this is (way) less than ideal and needs a better solution.
> But it's better than leaking in the meantime, until a better solution is
> found and implemented.
What happens if you muck with an instance after it's been finalize()'d ?
Since the reference is still around on the Python side, it's certainly
possible... I'd hope an exception rather than a segfault.
> Currently, all I can think of is a thread that runs every few seconds and
> that looks at all such Python extension instances. When it finds one that
> is not referred to by any code other than the Java wrapper itself (and a
> global list of such extensions), it would replace the java reference
> preventing the java side from being GC'ed with a Java weak reference
> allowing the java side to be GC'ed once Java's GC made the same
> determination, finalize() to be invoked by the Java GC and finally the
> Python side to be decref'd down to 0 and freed. I don't like this daemon
> thread idea very much but if I (or this list) can't come up with a better
> idea, I might just have to implement it.
I think you might want PhantomRefences?
http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/PhantomReference.html
"Phantom reference objects, which are enqueued after the collector determines
that their referents may otherwise be reclaimed. Phantom references are most
often used for scheduling pre-mortem cleanup actions in a more flexible way
than is possible with the Java finalization mechanism."
The ref package talks about how to use these things:
http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/package-summary.html
And a tutorial: http://www.javaworld.com/javaworld/javatips/jw-javatip79.html
HTH
--Pete
--
Peter Fein || 773-575-0694 || [EMAIL PROTECTED]
http://www.pobox.com/~pfein/ || PGP: 0xCCF6AE6B
irc: [EMAIL PROTECTED] || jabber: [EMAIL PROTECTED]
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
