I am not C programmer, and actually even don't know if this is any
problem at all. I just read a blog post that sounded a bit scary, and
wanted to ask people from Ruby side, is this actually a real problem
or just some rant/misunderstanding.

Here is the mentioned blog post: http://timetobleed.com/the-broken-promises-of-mrireeyarv/

Be warned, it was written in a *not* very nice manner...

The need for RB_GC_GUARD(v) is probably due to faulty register spilling
in the MRI eval/thread/GC machinery; the PRE_GETCONTEXT() and
POST_GETCONTEXT() macros in MRI eval.c might be the real problem.

In contrast, the Boehm-Demers-Weiser (BDW) GC library manages to flush
registers without demanding client code to explicitly flush pointers to
the stack.

However, in general, it is problematic, in language design practice to
make GC contracts completely transparent to API client code. This
difficultly is explicitly solved in the design of Lua:

Passing a Language through the Eye of a Needle How the embeddability
of Lua impacted its design: http://queue.acm.org/detail.cfm?id=1983083

Lua mediates all object references through stack manipulations. They
were able to implement a generational write-barrier with little (or no)
GC API contracts.

On Jul 6, 3:26 am, Ernest <est%iest...@gtempaccount.com> wrote: