"Lyle Johnson" <ljohnson / resgen.com> wrote:
[...]
>Ruby, of course, doesn't have the concept of C++ destructors. When the GC
>detects that an object is no longer in use, it will get "collected". So the
>problem I'm running into is that when object "Foo" gets garbage collected
>(and the underlying C++ object "CFoo" is destroyed), there are still other
>C++ objects out there that  have references to "CFoo". As soon as they try
>to access the recently deceased object, bad things happen.
>
>So the question is, is there any way to control the order in which objects
>get garbage-collected? For the current problem I'm debugging, all of this
>action is taking place when the Ruby interpreter shuts down. For those
>familiar with the source code, I'm looking at the function
>"rb_gc_call_finalizer_at_exit()", which is defined in gc.c. The second loop
>in this function loops over all the data objects and GC's them in an
>arbitrary order.
>
>Any suggestions are welcome...
>
Well as you see, gc and reference counting are not friends.

So 3 suggestions.

The first is to stop using reference counting.  (As already
suggested by Dave.)

That may not be easy, in which case you can map the idea of
destructors onto Ruby.  Then in any block that you create
one of your objects in, call that in an ensure clause.  Your
problem still exists, but if someone programs according to
your API, objects will be destroyed in a timely manner.  (If
you have resources to clean up, this is the right approach
to take to cleaning them.)

The third option is to hack Ruby to have a way you can
register a collection of objects that need to be
destroyed first in the global destruction.  Using WeakRef
you can register things in there without interfering with
them being garbage collected, and at the end of time you
know those things will go first.

Personally I would suggest the first or the second.

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com