Le mercredi 25 août 2010 14:16:30, Florent Monnier a écrit :
> > That's right. Therefore, calling caml_copy_string in noalloc mode is
> > probably not a good idea..
> 
> but no-one told to do so
> 
> there was a boxed value provided to the noalloc function,
> but this function does not call caml_copy_string at all

That's right, sorry for that. 

However, the function that has noalloc still has one call to 
caml_string_length and also a memcpy that depends on the pointer associated to 
the string value (String_val).

It seems to me that in both case, the C function may be "tricked" by the Gc, 
for instance if it reorganizes the memory, leaving the original pointer given 
to the C function pointing to a space in memory that no longer contains the 
allocated string.

For such things as strings and more generally pointers linking to underlying 
structures in memory, I think it is wise to use CAMLparamX and register the 
value so that it is not touched by the Gc during the C call.

Also, you may want to try to register the value as global root. However, we've 
had problems with this approach as well, though I do not recall exactly why. 

Finally, even if you do not release the global lock in the function 
(caml_enter_blocking_section), still, calling for instance caml_string_length 
may trigger a Gc recollection.

Now, I may be wrong. In this case, I hope someone can correct me :)


Romain