From: Robert Klemme <shortcutter@...>
Date: 2008-01-10T03:39:59+09:00
Subject: Re: why does this code leak?

On 09.01.2008 19:26, Rick DeNatale wrote:
> On Jan 9, 2008 11:45 AM, ara howard <ara.t.howard@gmail.com> wrote:
>> On Jan 9, 2008, at 9:39 AM, dan yoder wrote:
>>
>>> I realize the scope of the lambda invocation is different in this
>>> example, but since the behavior is so similar, I thought it likely
>>> pointed to the same underlying issue.
>> i think it's actually some strange interaction with yaml.  check this
>> out:
> ..
>> if ARGV.detect{|arg| arg["leak"]}
>>   require "yaml"
>>   7.times {
>>     GC.start
>>     y c.name => ObjectSpace.each_object(c){}
>>     c.new
>>   }
>> else
>>   7.times {
>>     GC.start
>>     puts "---"
>>     puts "#{ c.name }: #{ ObjectSpace.each_object(c){} }"
>>     c.new
>>   }
>> end
>>
>> cfp2:~ > ruby a.rb
>> ---
>> Array: 6
> 
>> cfp2:~ > ruby a.rb leak
>> ---
>> Array: 21
> 
> Not sure how you got there Ara, I don't see where the OP ever mentioned YAML.

Rick, OP == ara => true. :-)

> I think the key is where the lambda is created. The lambda is
> capturing the binding.

In his revisited example (msg id 
F36A72A4-6216-4251-BF98-D231597C7B0D@gmail.com) the non leaky finalizer 
had self bound to Class and the non leaky to the particular class 
instance.  I believe Ara's confusion stems from the question how a class 
instance can keep instances in memory.

> In the first case the lambda is being created in the bindig context of
> the class, and in particular self is the class.
> 
> In the second case, the lambda is being created in the binding context
> of the new instance, and self is that new instance, so the lambda in
> the finalizer is hanging on to it.

That's not true for the posting I mentioned above and also not for the 
last one.  There was only one finalizer but one branch used yaml while 
the other did not.

Kind regards

	robert