caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Brown <caml-list@davidb.org>
To: Samuel Mimram <samuel.mimram@ens-lyon.org>
Cc: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] interaction between *_blocking_section and value
Date: Wed, 2 Mar 2005 16:28:36 -0800	[thread overview]
Message-ID: <20050303002836.GA30339@old.davidb.org> (raw)
In-Reply-To: <42263EE3.6020701@ens-lyon.org>

On Wed, Mar 02, 2005 at 11:32:03PM +0100, Samuel Mimram wrote:

> I'd like to have some clarifications about the interaction between 
> threads and the GC in C bindings.
> As far as I understand the CAMLparam and CAMLlocal macros prevent values 
> from being garbage-collected i.e.
> 1. being completely removed from memory,
> 2. being *moved*
> during the whole scope of the C function (am I right?).
> I have received a mail concerning one of my programs which was telling 
> me that this is not true when in blocking sections, and that values can 
> be moved by the GC. Is it the case? Consider the following code:
> 
> CAMLprim value caml_send(value data)
> {
> 	CAMLparam1(data);
> 	enter_blocking_section();
> 	send(0, String_val(data), string_length(data));
> 	leave_blocking_section();
> 	CAMLreturn(Val_unit);
> }
>
> Is it safe or can the String_val(data) point to an invalid portion of 
> memory because data have been move by the GC because of the 
> enter_blocking_section()?

The CAMLparamxxx macros only register these variables as additional roots.
In particular, only your first statement above is true.  The garbage
collector is free to move the values.  However, because the roots have been
registered, the variable (data) itself will be modified whenever the
garbage collector moves the data it points to.  Most importantly, you
should not have other variables that also contains these same values.

So, the problem with the above code is that the garbage collector is free
to move the contents of data around, and it might happen when send blocks.

Generally, you should copy the data in an instance such as this before
passing the data on to the additional function.

> Also, it would be nice if the *_blocking_section() could be explained in 
> the documentation.

It does different things, depending on what thread implementation you are
using, but the basic idea is that there is a mutex kept that needs to be
held while running caml code.  enter_blocking_section releases the mutex,
and leave_blocking_section re-acquires the mutex.  It also changes how
signal handling is done, to allow the operation to be interrupt by a
signal.

Dave


      reply	other threads:[~2005-03-03  0:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-02 22:32 Samuel Mimram
2005-03-03  0:28 ` David Brown [this message]

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=20050303002836.GA30339@old.davidb.org \
    --to=caml-list@davidb.org \
    --cc=caml-list@inria.fr \
    --cc=samuel.mimram@ens-lyon.org \
    /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).