On Jan 9, 2008 3:46 PM, ara howard <ara.t.howard / gmail.com> wrote:
>
> On Jan 9, 2008, at 1:42 PM, Rick DeNatale wrote:
>
> > Ah, missed that.
> >
> > Anyway ara re-asked the question on ruby-core and Matz answered him
> > pretty much the same way I did.
>
> sort of - i still don't see how
>
> 1) the 'object' ended up being bound.  it was a local var of another
> function.  makes no sense.

I think that this is the code you are talking about right?

  class Class
    Finalizer = lambda { }

    def leak_free_finalizer
      Finalizer
    end

    def leaky_finalizer
      # What's self here? It's the same as for the finalizer method
      # which
      lambda{}
    end

    def finalizer
      %r/leak/ =~ ARGV.first ? leaky_finalizer : leak_free_finalizer
    end

    def new *a, &b
      object = allocate
      object.send :initialize, *a, &b
      object
    ensure
      ObjectSpace.define_finalizer object, finalizer
    end
  end

Looking at eval.c, it looks like lambda actually copies information
from the invocation stack, not just from the current frame. In the
leaky finalizer case we have the following on the stack when
leaky_finalizer is called, with the binding represented in hash
notation.

leaky_finalizer   :self => Class
finalizer               :self => Class
new                      :self=> Class, :object => the new Array instance
code which called Array.new

The leak free finalizer lambda was created once at a time when no
instance to be finalized was on the stack.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/