2010/7/4 Itamar Syn-Hershko <ita...@code972.com>: > 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.
As far as I have understand the exception handling in C++, throwing an exception can lead to an immediately termination of an application, if the exception is thrown within in a stack unwinding because of another exception thrown before. > 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? There seems to be some dependencies between the different IndexReaders sharing the same resources. Maybe that's the reason, why close() has to be called explicitly. 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
