caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Romain Beauxis <toots@rastageeks.org>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] caml_copy_string
Date: Wed, 25 Aug 2010 14:33:06 -0500	[thread overview]
Message-ID: <201008251433.07764.toots@rastageeks.org> (raw)
In-Reply-To: <201008252116.30488.monnier.florent@gmail.com>

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


  reply	other threads:[~2010-08-25 19:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-21 23:30 caml_copy_string Jeffrey Barber
2010-08-21 23:42 ` [Caml-list] caml_copy_string Romain Beauxis
2010-08-21 23:46 ` Mathias Kende
2010-08-22 17:16   ` Till Varoquaux
2010-08-23  0:42     ` Till Varoquaux
2010-08-23  1:02       ` Jeffrey Barber
2010-08-23 12:09 ` Florent Monnier
2010-08-23 12:59   ` Stéphane Glondu
2010-08-23 13:46     ` Florent Monnier
2010-08-23 20:24   ` Romain Beauxis
2010-08-24 14:21     ` Florent Monnier
2010-08-24 14:52       ` Till Varoquaux
2010-08-24 15:22         ` Anil Madhavapeddy
2010-08-24 15:35           ` Romain Beauxis
2010-08-25 19:16             ` Florent Monnier
2010-08-25 19:33               ` Romain Beauxis [this message]
2010-08-25 15:21   ` Goswin von Brederlow
  -- strict thread matches above, loose matches on Subject: below --
2005-10-29  0:24 Jonathan Roewen
2005-10-29  0:32 ` Robert Roessler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201008251433.07764.toots@rastageeks.org \
    --to=toots@rastageeks.org \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).