ability to run finalizers at a given point of a program?

[ts]

P> thanks for the hint. I know you don't like to write in English, but
P> could you please try to explain why the assignment makes a difference?

Well don't look at this, this is not really interesting.

The biggest problem that I've seen is that you "think" at ruby level when
the GC work at C level.

The assignement is just to make sure that the GC will not find the object
and this is really dependent on the ruby version.


Guy Decoux

 

[Pit Capitain]

P> thanks for the hint. I know you don't like to write in English, but
P> could you please try to explain why the assignment makes a difference?

Well don't look at this, this is not really interesting.

The biggest problem that I've seen is that you "think" at ruby level when
the GC work at C level.

The assignement is just to make sure that the GC will not find the object
and this is really dependent on the ruby version.

OK, I still don't understand, but your hint helped me to finally get my
finalizer unit tests working, so thanks again.

Regards,
Pit

 

[Guillaume Cottenceau]

Wait.. both calls to define_finalizer have a reference to foo as the

Incorrect. The first argument is irrelevant.
ObjectSpace::define_finalizer is written this way probably to make
things ugly. You have to pass in the object you wish to attach a
finalizer to, and that's what the first arg is for.

I wasn't pretending it would retain a reference, I was just comparing
both versions and underlined that both had that.

In your version, foo is in-scope when the finalizer proc is created, so
the proc captures foo *even though it is not explicitly used in the
proc*. That's right! Just because you don't reference foo inside a
closure doesn't mean it magically disappears for you.

Thanks, I was wrong on that very matter. I thought a closure only
captured the necessary environment, not the whole of it (what is
necessary being decided at closure creation time). And I can't
duplicate such ruby's behaviour in perl :/ Perl in my example doesn't
capture the whole environment when creating the closure:

http://www.zarb.org/~gc/t/prog/closures_wholecapture/

 

[Guillaume Cottenceau]

In your version, foo is in-scope when the finalizer proc is created, so

the proc captures foo *even though it is not explicitly used in the
proc*. That's right! Just because you don't reference foo inside a
closure doesn't mean it magically disappears for you.

After a second thought, I then think that it reduces a lot the use of
the finalizer, because it means that it cannot do anything related to
the instance of the object being destroyed, or else it will retain a
reference to the object as you explain, right? If the closure,
wherever created, has a reference to any attribute of the class for
example.

 

[ts]

G> After a second thought, I then think that it reduces a lot the use of
G> the finalizer, because it means that it cannot do anything related to
G> the instance of the object being destroyed,

This is worst that you think

svg% cat b.rb
#!/usr/local/bin/ruby
obj = []
ObjectSpace.define_finalizer(obj, proc { p "before"; p obj; p "after" })
svg%

svg% b.rb
"before"
svg%



Guy Decoux

 

[Robert Klemme]

G> After a second thought, I then think that it reduces a lot the use of
G> the finalizer, because it means that it cannot do anything related to
G> the instance of the object being destroyed,

Not necessarily: you can keep a reference to a member instance that needs
cleanup. Also, the finalizer receives the oid which you can use for
bookkeeping purposes.

This is worst that you think

svg% cat b.rb
#!/usr/local/bin/ruby
obj = []
ObjectSpace.define_finalizer(obj, proc { p "before"; p obj; p "after" })
svg%

svg% b.rb
"before"
svg%

Interesting. IMHO the finalizer should not be called in the first place
as it retains a ref to "obj".

robert