Re: Data_Make_Struct Considered Dangerous?

[e-mail] wrote in message news:<[e-mail]>...
---------------------------------------------------
> It sounds strange.  Data_Make_Struct() fills the allocated
> structure with 0 and rb_gc_mark() ignores 0 which is equal to
> Qfalse.
---------------------------------------------------
I think this can only happen when we have a struct/class inside
another struct/class.  What I observed is, while we are creating the
inner struct/class, gc gets called and try to mark the outer
struct/class.  Are you saying that even in this case it is safe
because the outer struct/class should all be filled with zeros?

--------------------------------------------------
> Also, since GC may be invoked while Data_Wrap_Struct()
> allocates new Data object, your conclusion isn't so meaningful.
--------------------------------------------------

Yes, it is not a foolproof way.  It just tries to get the programmer's
attention and prevent error, because, I think, a good C programming
way is always to fill the data right after we do a memory allocation:

    ptr = (myType*) malloc (sizeof (myType));
    ptr->data_1 = val;
    ...
    ptr->data_N = val;

(here ptr results from another Data_Make_Struct).  This programming
discipline usually works, unless, of course, when we initialize a
member with another Data_Make_Struct():

    ptr = (myType*) malloc (sizeof (myType));
    ptr->data_1 = val;
    ...
    ptr->data_k = Data_Make_Struct (...);

In this case, the C programmer has to realize that that seemingly
innocent function is actually very complicated, which may invoke gc
which results in the calling of all marking functions.  Therefore, in
Ruby the C programmer has to add another discipline of
"double-initializing":

    ptr = (myType*) malloc (sizeof (myType));
    ptr->data_1 = val;
    ...
    ptr->data_k = Qnil;    /* or Qfalse actually better? */
    ptr->data_k = Data_Make_Struct (...);

Based on your response above, are you saying that this
"double-initializing" is actually not needed?  (in which case, the
error is actually generated somewhere else?)  I just need some
assertion here, because I cannot fix something that is working or
considered working.

-------------------------------------------------
> Additionaly, you can use ruby_xfree for free.
-------------------------------------------------
I am sorry.  In my Ruby-C way, I will stay far from Ruby as much as
possible.  So instead of having a combination of ALLOC and ruby_xfree,
I just use (at least) malloc() and free().  One problem of using Ruby
memory allocator is that it is tied to a garbage collector.  Yes,
using garbage collector makes a programmer/user's world less
complicated.  However, the drawbacks of garbage collector are, at
least:

    1) The calling of marking functions is a kind of waste for objects
that have full life (until the process itself is killed) or long
duration.  This kind of objects should not be managed by gc; instead
they should be managed by C.

    2) It makes it difficult to do real-time programming (I have seen
a discussion on this in this newsgroup.)

In point 2) above, actually I am not saying that Ruby will never be
appropriate for stuff related to real-time programming.  If we design
the software careful enough, we still can provide input spec in Ruby,
and then run the kernel (in C) in real-time (by making GC.disable). 
Of course, there will be cases where setting GC.disable is impossible
because of some continual new memory consumption.  However, if we
design the software careful enough, we increase the number of cases
where GC can indeed be disabled.  Furthermore, even where GC has to be
enabled, our software is much more execution-efficient, because the
calling of marking functions has been minimized; this is in regards
with point 1) above.  (Currently I have only one marking function,
which is down from about six when I originally started writing the C
extension; this was accomplished by redesigning the data structure.  I
still want to get rid of that one marking function...)

Regards,

Bill