From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 77F5FBC0B for ; Thu, 25 Jan 2007 19:30:01 +0100 (CET) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0PIU2ZN013757 for ; Thu, 25 Jan 2007 19:30:04 +0100 Received: from ppp27-234.lns1.syd6.internode.on.net (HELO rosella) ([59.167.27.234]) by ipmail01.adl2.internode.on.net with ESMTP; 26 Jan 2007 04:59:57 +1030 X-IronPort-AV: i="4.13,239,1167571800"; d="scan'208"; a="78771576:sNHT21188391" Subject: Re: [Caml-list] Interfacing with C question... From: skaller To: Hendrik Tews Cc: caml-list@yquem.inria.fr In-Reply-To: References: <002d01c73fdc$6254d430$6a7ba8c0@treble> Content-Type: text/plain Date: Fri, 26 Jan 2007 05:29:55 +1100 Message-Id: <1169749795.5333.17.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45B8F72A.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; interfacing:01 0100,:01 hendrik:01 tews:01 fwiw:01 pointers:01 unboxed:01 sourceforge:01 wrote:01 imho:01 integer:01 writes:01 caml-list:01 exceptions:01 macros:01 On Thu, 2007-01-25 at 17:26 +0100, Hendrik Tews wrote: > "David Allsopp" writes: > > Sorry if this an RADBOTFM case. > And you cannot use CAMLlocal or > register_global_root, FWIW: I encourage people not to just use the high level macros like CAMLlocal: they hide what really happens. Instead, read the section describing the lower level macros and figure out how the gc *actually* works. Roughly speaking the rules are: (a) certain operations, including allocation, trigger the gc. (b) you must ensure allocated store is initialised when the gc is triggered (so it doesn't chase off into the wild blue yonder) (c) you may not retain copies of values in stores across calls that trigger the gc because it may move blocks and adjust pointers (d) there are some exceptions: if the value is an integer or unboxed float it won't change (obviously). (e) Every allocated block you want to use must be reachable from a root when the gc is triggered The high level macros reduce thinking by making variables a root and ensuring they're initialised, however they're conservative and may incur a performance overhead by doing this when it isn't necessary. For any kind of serious glue logic you really need to understand the low level requirements, in particular the fact stuff moves means you have to know precisely when the gc is triggered anyhow -- since you can't write C without temporary creation and sequence points being considered. It takes a bit of reading, thinking, and question asking to figure the gc out, but it is worth it: it really isn't that hard and IMHO the higher level macros just confuse things by obscuring the real constraints. [Once you know how it works .. *then* you can use the higher level macros because you then know what they're sugar for .. :] -- John Skaller Felix, successor to C++: http://felix.sf.net