From: Robert Buck <lists@...>
Date: 2012-11-26T02:29:11+09:00
Subject: Re: C Extension: Why would VALUE state appear differently during shutdown than immediately before it

I hear what you are saying Bill. I am writing up my thoughts on how to
do this much better than my interim, NuoDB RC2, release. You referred to
VALUE**, in effect. Here were my thoughts, in progress, still polishing
them up and thinking through all the use-cases in terms of language
integration, all permutations of code folks could write (read my thread
I just sent to Takehiro referring to a bifurcation of the internally
managed objects), but this will give you a glimpse:

struct os_entity // internal stuff, user managed or ref count managed
{
    void * data_handle;
    unsigned int flags;
    rb_atomic_t refers;

    callback incr_func;
    callback decr_func;
    callback free_func;

    os_entity * parent;
};

struct gc_entity // what the gc sees and manages
{
    os_entity * entity;
    VALUE ** marks;
};

You mentioned a list of VALUE*, yes, this was where my thoughts were
leading me. But as out of order frees can occur at shutdown, these
VALUE** only are used in the mark phase, and I do not traverse the graph
of VALUE references, rather traverse the internal graph of os_entity
objects, as I call them (for lack of a better name).

Comment if you are interested, I will share the net result on Github
when I am done. For RC2 of NuoDB, the updated Ruby driver will show up
on Github within a day or two, which has some ideas incorporated from
you folks. I'd live for folks to comment on my code there (but please,
not on what exists there till after Nov 27, 2012.

Admin Tensor wrote in post #1086223:
> Robert Buck wrote in post #1086213:
>
>> struct hierarchical_handle
>> {
> .......
>>     // used to pin parents in memory via rb_gc_mark
>>     VALUE parent;
>> };
>
> Hi,
>
> Just a little comment here.  If I have to to traverse a graph of
> objects, I will use something similar to "VALUE* children" instead of
> "VALUE parent" for rb_gc_mark (and it is more true for the free function
> pointers).
>
> Regards,
>
> Bill

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