interaction between *_blocking_section and value

interaction between *_blocking_section and value

[Samuel Mimram]

Hello,

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()?

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

Thanks.

Regards,

Samuel.

Re: [Caml-list] interaction between *_blocking_section and value

[David Brown]

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