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-Hershko<ita...@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
