Browse thread
When can we ignore CAMLparam and CAMLreturn?
-
Jianzhou Zhao
-
Jacques Garrigue
- Goswin von Brederlow
-
Jacques Garrigue
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Goswin von Brederlow <goswin-v-b@w...> |
| Subject: | Re: [Caml-list] When can we ignore CAMLparam and CAMLreturn? |
Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:
> On 2010/10/26, at 1:19, Jianzhou Zhao wrote:
>
>> Hi All,
>>
>> Here is the code from LLVM-OCaml bindings.
>>
>> /////////////////
>> /* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */
>> CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args,
>> LLVMExecutionEngineRef EE) {
>> unsigned NumArgs;
>> LLVMGenericValueRef Result, *GVArgs;
>> unsigned I;
>>
>> NumArgs = Wosize_val(Args);
>> GVArgs = (LLVMGenericValueRef*) malloc(NumArgs * sizeof(LLVMGenericValueRef));
>> for (I = 0; I != NumArgs; ++I)
>> GVArgs[I] = Genericvalue_val(Field(Args, I));
>>
>> Result = LLVMRunFunction(EE, F, NumArgs, GVArgs);
>>
>> free(GVArgs);
>> return alloc_generic_value(Result);
>> }
>> ////////////////////////
>>
>> The 'llvm_ee_run_function' does not protect the Args parameter by
>> CAMLparam with CAMLreturn. Is this safe in this case, because we
>> allocated a GVArgs? The Ocaml manual suggests to use CAMLparam for any
>> value parameters (http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc140).
>
> The basic rule is that those macros are only needed if some allocation in the caml heap
> occurs before accessing a caml value. Expressed another way, whenever allocation is
> used all unprotected pointers to the caml heap should be considered as invalid.
>
> Since in the above code there is no allocation in the caml heap before the Genericvalue_val's,
> Args need not be protected. Similarly for the result, we are just returning the result of another
> function, with no risk of corruption.
>
> When in doubt, it is always safer to use CAMLparam/CAMLreturn, eventhough they will
> generate a bit more code.
As a special case: If you enter/leave_blocking_section() then some other
thread might (almost certainly will) do an allocation. So any ocaml
values you need in enter/leave_blocking_section() need to be copied to C
values beforehand and values you need after need to be protected.
MfG
Goswin