I tend to agree with Veit. Although JL doesn't have a finalize method, I
think it does make sense to automatically call close in the desctructor
of both Index writer and reader.
I'm not sure asserting in a destructor, or throwing an exception, will
do any good.
But is calling close() from ~IndexReader is safe at all times (even like
if (!this-closed) close(); ) ?
I tried it, and it resulted in an assertion from one of the iterations
in TestIndexReader.cpp :: performDefaultIRTests -- deleting one of the
readers in the 3rd iteration or so is hitting a double dec-ref.
Since I couldn't find a similar test in the JL suite, one could question
the validity of it (I'm not the original author). I think the best
measurement for this is if we port all the Java tests from
TestIndexWriter and TestIndexReader and they all pass fine + some
concurrency tests from the atomicthreads branch (+ some new tests for
that end), and they all pass also with a call to close() on the destructor.
What do you think?
Itamar.
On 2/7/2010 9:19 PM, Kostka Bořivoj wrote:
I'm not sure if close should be called from destructor or not, but if not
some assert
in destructor if IndexReader is not closed would be helpful
Borek
-Original Message-
From: Veit Jahns [mailto:nuncupa...@googlemail.com]
Sent: Thursday, July 01, 2010 10:12 PM
To: clucene-developers@lists.sourceforge.net
Subject: Re: [CLucene-dev] cl_demo memory leaks discovery
2010/7/1 Itamar Syn-Hershkoita...@code972.com:
On one hand, we should be following the Java behavior. If they always
call close, we should always do as well. When having a reader object on
the stack this is definitely how that should work. On the other hand, if
calling close from the destructor is not a big deal (concurrency is the
biggest impact I can think of right now) I guess it is better doing so
than relying on a GC we don't have.
In my opinion the missing GC is a good reason to deviate from the Java
behaviour.
Veit
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
CLucene-developers mailing list
CLucene-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clucene-developers
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
CLucene-developers mailing list
CLucene-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clucene-developers
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
CLucene-developers mailing list
CLucene-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clucene-developers
