From: Robert Buck <lists@...>
Date: 2012-11-22T00:09:49+09:00
Subject: Re: C Extension Shutdown GC vs Free Functions Called

Unsure if this really applies. Could you restate? I am not quite 
following you.

Let me provide additional details...

The use case is a database driver where a connection begets prepared 
statement objects which begets result set objects which begets column 
info objects.

At each layer of objects we wrap its corresponding struct using 
Data_Wrap_Struct as each object has functions (written in C) exposed to 
Ruby that may operate on it.

I did set this up so that the child objects have a VALUE reference to 
its parent.

But it certainly is the case that Ruby does not do one last Mark and 
Sweep before it shuts down after removing all entries from the object 
table. Instead it appears as though Ruby simply does a bulk delete 
willy-nilly with no concerns about deletion order (which minimally 
should occur in at least reverse order of allocation, again which Ruby 
does not do).

Admin Tensor wrote in post #1085669:
> Robert Buck wrote in post #1085583:
>> It was my assumption that during shutdown the objects would be freed
>> leaf objects first, and a mark and sweep like approach. It seems however
>> that Ruby just walks an object table and frees each in entry order.
>>
>> For native (C/C++) object graphs this can lead to out of order
>> deallocations. In my particular case this leads to a SEGV.
>
> Hi,
>
> If you have to free the objects in certain order, in C/C++ you have to
> record only one Ruby object which is the root, then you create pointers
> to all other leaf (non-root) Ruby objects; in the free function
> pointers, you set all the leaf (non-root) Ruby objects as NULL.
> Hopefully you don't create too many temporary leaf (non-root) objects,
> as all we be freed only when root is freed.
>
> Regards,
>
> Bill

-- 
Posted via http://www.ruby-forum.com/.