From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 785A4BBAF for ; Wed, 27 Oct 2010 15:32:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAK/Gx0xKfVIukGdsb2JhbAChUQgVAQEBAQkJDAcRAx+hcYtvhg4jiGIBAQMFhUMEilOJHQ X-IronPort-AV: E=Sophos;i="4.58,246,1286143200"; d="scan'208";a="85590461" Received: from mail-ww0-f46.google.com ([74.125.82.46]) by mail1-smtp-roc.national.inria.fr with ESMTP; 27 Oct 2010 15:32:18 +0200 Received: by wwd20 with SMTP id 20so730141wwd.3 for ; Wed, 27 Oct 2010 06:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=K3BXX9QdNINU943ETj4t0/r+mgaSbjUWVQZcEHt7lzI=; b=yH6uau1KqCOCfggZ+F53oRmldDkOFt1AsAzlp4o0CPKRYdKHZeg3ByHsBDYMoocsx9 D8/au/tMbBhoqIZUGL5YX25BXNvqK91Nep/0aerg+AjjoqNQUvfxXXj9hC5agXhIvKGP c8cjRxgGmkXN6dNOBP40EQU9Yt3I78qiUcsN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eTKSiQyUZ2Sj7AJxKPLFdkw90nEAAqSzbQHfnz5FmWnOZzdxTLk9Si3nrP2MUGq8Dx wRaSMf/RgO0qzfuHvUgajAsxQo/whn1tAmJ09hoqUOQl/v5VfRQNkoS4AbxDUONAcqQ+ 917p1v+yHBCFlcAigNWOb3/3YdpN/MPn+HpnY= MIME-Version: 1.0 Received: by 10.227.141.71 with SMTP id l7mr2079848wbu.68.1288186337851; Wed, 27 Oct 2010 06:32:17 -0700 (PDT) Sender: jianzhou.zh@gmail.com Received: by 10.217.0.80 with HTTP; Wed, 27 Oct 2010 06:32:17 -0700 (PDT) In-Reply-To: <8739rsdljr.fsf@frosties.localdomain> References: <8739rsdljr.fsf@frosties.localdomain> Date: Wed, 27 Oct 2010 09:32:17 -0400 X-Google-Sender-Auth: yfSAKSJO5n18pVt65Oyo8EYKuy0 Message-ID: Subject: Re: [Caml-list] When can we ignore CAMLparam and CAMLreturn? From: Jianzhou Zhao To: Goswin von Brederlow Cc: Jacques Garrigue , caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; camlparam:01 camlreturn:01 bindings:01 camlprim:01 wosize:01 val:01 malloc:01 sizeof:01 val:01 alloc:01 function':01 camlparam:01 camlreturn:01 ocaml:01 pointers:01 On Wed, Oct 27, 2010 at 5:36 AM, Goswin von Brederlow w= rote: > Jacques Garrigue 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, >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LLV= MExecutionEngineRef EE) { >>> unsigned NumArgs; >>> LLVMGenericValueRef Result, *GVArgs; >>> unsigned I; >>> >>> NumArgs =3D Wosize_val(Args); >>> GVArgs =3D (LLVMGenericValueRef*) malloc(NumArgs * sizeof(LLVMGenericVa= lueRef)); >>> for (I =3D 0; I !=3D NumArgs; ++I) >>> =A0 GVArgs[I] =3D Genericvalue_val(Field(Args, I)); >>> >>> Result =3D 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 i= n the caml heap >> occurs before accessing a caml value. Expressed another way, whenever al= location is >> used all unprotected pointers to the caml heap should be considered as i= nvalid. >> >> Since in the above code there is no allocation in the caml heap before t= he Genericvalue_val's, >> Args need not be protected. Similarly for the result, we are just return= ing the result of another >> function, with no risk of corruption. >> >> When in doubt, it is always safer to use CAMLparam/CAMLreturn, eventhoug= h 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 > =A0 =A0 =A0 =A0Goswin > Does it imply that, if any Ocaml binding uses enter/leave_blocking_section, the Ocaml runtime only switch contexts at enter/leave_blocking_section(). If it allows other threads run at any point, we might have to protect values in any function. --=20 Jianzhou