--- nobu.nokada / softhome.net wrote:
> At Mon, 20 Jun 2005 00:30:59 +0900,
> Eric Mahurin wrote in [ruby-talk:145818]:
> > > Finailizers don't run immediately after the corresponding
> > > objects get collected.  The `finalizer' runs at the
> process
> > > termination.
> > 
> > This is what the documentation says about define_finalizer:
> > 
> > ---
> > Adds aProc as a finalizer, to be called when obj is about
> to be
> > destroyed.
> > ---
> 
> The documentation is inaccurate or improper.  Finalizers have
> never be called before the destruction.
> 
> > I catch the RangeError (recycled object) exceptions and
> > Thread.critical is still true ("E" gets printed), but the
> > finalizer still happily runs.  I guess GC and the finalizer
> are
> > still considered to be part of the same thread even though
> > functionally it seems like a different one.
> 
> That guess is right.  But I didn't see "E" nor "e" from your
> new example, because GC.start does run finalizers. 
> Commenting
> the line out, "E" was printed.

Sorry.  I meant to comment out the GC.start.  Putting in the
GC.start (sometimes I need 2 of them back-to-back) gets it to
work, but I don't want the penalty of running GC all the time.

> > I realize that catching RangeError's would fix 99% of the
> > problems.  But, I would still be concerned about the case
> where
> > the object would be GCed and then the space reclaimed by an
> > object that looks just like it.  Is it guaranteed that
> > finalizers of the orginal object be run before its space is
> > reclaimed?
> 
> They are called after all destruction has done. 

And before any of that space is reclaimed?  It seems like
normal Ruby processing (including memory allocation) can occur
during GC and between GC and finalizers.

> > a. When are object finalizers called?  The docs don't
> reflect
> > the behavior.
> 
> Within evaluation loop after a method implemented in C ended.
> It is possible to change it more frequently (e.g., for each
> instructions), but I've not measured how it affects the
> performance.

For future Ruby revisions, I think you should consider ensuring
that after an object is GCed its finalizers are called before
normal ruby processing continues.  Having normal ruby code have
to deal with the situation where an object has been GCed but
its finalizers haven't been called seems unnecessary.

> > b. What does GC.disable do?
> 
> Prohibits running GC.  If free slots are exhausted while GC
> is
> disabled, the interpreter just tries to allocate new slots
> with
> malloc().

So, it works immediately, but this GC.disable could have
occured between an object being GCed and its finalizers being
called.  The finalizers could still continue while GC is
disabled.



		
__________________________________ 
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html