English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-08-25 (19:31)
From: Romain Beauxis <toots@r...>
Subject: Re: [Caml-list] caml_copy_string
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 :)