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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4DE17BB83 for ; Sat, 13 May 2006 01:48:01 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4CNm0nj028371 for ; Sat, 13 May 2006 01:48:00 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA32389 for ; Sat, 13 May 2006 01:48:00 +0200 (MET DST) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4CNlx4X003794 for ; Sat, 13 May 2006 01:47:59 +0200 Received: by wx-out-0102.google.com with SMTP id h26so401033wxd for ; Fri, 12 May 2006 16:47:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z9bmzEKaqTYlLQ1N7h445rqbivAXqeImDtuklzs7MZc4JD0pL0+Ivkv9d3ggo6Js2QToMqVFW2gQ7uJ2i3m9x/mOY85ptf3y3fcGF9meF+KcFrJ/J6hvfPxrr25eifEstytIFsVi2k5lHUmB6mfREqLbLAgl/O53MgIf/kaiR3U= Received: by 10.70.44.8 with SMTP id r8mr3529425wxr; Fri, 12 May 2006 16:47:58 -0700 (PDT) Received: by 10.70.56.17 with HTTP; Fri, 12 May 2006 16:47:58 -0700 (PDT) Message-ID: Date: Fri, 12 May 2006 19:47:58 -0400 From: "Markus Mottl" To: "Hendrik Tews" Subject: Re: [Caml-list] two questions for keeping harmony (with the garbage collector) Cc: caml-list@inria.fr In-Reply-To: <17509.4927.287237.266015@ithif59.inf.tu-dresden.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17509.4927.287237.266015@ithif59.inf.tu-dresden.de> X-j-chkmail-Score: MSGID : 44651EAF.000 on nez-perce : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 44651EB0.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44651EAF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 garbage:01 hendrik:01 tews:01 tews:01 camlparam:01 camlreturn:01 pointer:01 pointer:01 ocaml-heap:01 camlparam:01 threads:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=INFO_TLD,RCVD_BY_IP autolearn=disabled version=3.0.3 On 5/12/06, Hendrik Tews wrote: > 1. About rule 1: CAMLparam / CAMLreturn can be ommitted in the > following cases: > > a) there is no value in the function that is a pointer to a > block inside the heap. If you do not have a pointer into the OCaml-heap (i.e. nothing of type "value"), then there is naturally nothing to protect. I sometimes prefer the Begin_roots/End_roots-macros defined in memory.h if I want to protect values allocated locally. I always use the CAMLparam/return macros to protect function arguments. > b) no allocation will take place between the start and the end > of the function. (Really? Even in the presence of threads?) It depends. If you use threads and call "caml_{enter,leave}_blocking_section" within the function and have a value whose lifetime extends into (e.g. I/O-operations on bigarrays) or crosses this block, then you will have to protect this value, because the GC may be called within the blocking section by another thread, which might reclaim the value. If any of the above requirements does not hold and if you don't allocate anything before using that value (standard case), then you don't have to protect the value. > 2. I believe rule 2 (register with CAMLlocal) must be extended to > intermediate values. Consider for instance > > value f(...); > value g(...); > > ... > h(f(...), g(...)); > > Assuming right to left evaluation, this will break if the > garbage collector is called inside f, because the value > returned by g is not registered as a root. True, this might break. > However, the following is save: > > h2(g(...)) > > because h2 will register the value before any allocation can > happen. Yes, this is safe. Regards, Markus --=20 Markus Mottl http://www.ocaml.info markus.mottl@gmail.com