From: Eric Wong <normalperson@...>
Date: 2013-05-14T05:28:38+09:00
Subject: [ruby-core:54971] Re: [ruby-trunk - Bug #8399] Remove usage of RARRAY_PTR in C extensions when not needed

"dbussink (Dirkjan Bussink)" <d.bussink@gmail.com> wrote:
> We don't want to expose GC managed memory like this directly to a C
> extension, that is on concern and why we copy. Even if we would
> directly expose it, it would still be problematic and still perform
> much worse because we would have to scan every array when going back
> into Ruby land because of the GC write barrier. Someone could have set
> a pointer to a young object in a mature array and all hell would break
> loose if we wouldn't do that. Since we don't know what people will do
> when using RARRAY_PTR() we always have to do these safety checks. What
> if we in Rubinius decide we don't want contiguous memory for arrays
> but something rope like? The C-API should not put up restrictions on
> this when this is not necessary.

Thanks for the response.  Until non-contiguous array is implemented,
I think RARRAY_PTR can be made fast + safe for read-only access arrays.

Frozen arrays should benefit automatically.

Perhaps RARRAY_PTR_RO can be introduced to declare read-only access on
non-frozen array.  Some code would be easier to update with this macro.
This would make sense in MRI, too.