Re: [CLucene-dev] cl_demo memory leaks discovery

[Itamar Syn-H. <it...@co...>]

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:nun...@go...]
>> Sent: Thursday, July 01, 2010 10:12 PM
>> To: clu...@li...
>> Subject: Re: [CLucene-dev] cl_demo memory leaks discovery
>>
>> 2010/7/1 Itamar Syn-Hershko<it...@co...>:
>>      
>>> 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
>> CLu...@li...
>> 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
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>
>
>