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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EEACBBBAF for ; Fri, 8 May 2009 11:36:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisCAOCZA0rUGyoBlGdsb2JhbACXEgEBAQEJCwgJEQO4JoN9BQ X-IronPort-AV: E=Sophos;i="4.40,316,1238968800"; d="scan'208";a="39641826" Received: from smtp1-g21.free.fr ([212.27.42.1]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 May 2009 11:36:57 +0200 Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id AB0E79400F9; Fri, 8 May 2009 11:36:51 +0200 (CEST) Received: from [192.168.1.3] (che78-2-82-237-71-191.fbx.proxad.net [82.237.71.191]) by smtp1-g21.free.fr (Postfix) with ESMTP id 62441940078; Fri, 8 May 2009 11:36:48 +0200 (CEST) Message-ID: <4A03FD30.6020307@inria.fr> Date: Fri, 08 May 2009 11:36:48 +0200 From: Xavier Leroy User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: Markus Mottl Cc: OCaml List Subject: Re: [Caml-list] Custom blocks and finalization References: <49FB04A9.3090008@soton.ac.uk> <4A01BB13.1040602@soton.ac.uk> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; markus:01 mottl:01 byterun:01 globroots:01 manipulates:01 runtime:01 runtime:01 ocaml:01 finalizer:01 allocating:01 finalizer:01 camlparam:01 foresee:98 wrote:01 exception:01 Markus Mottl wrote: >> Let's have a look at byterun/globroots.c: > [snip] >> So... how could caml_remove_global_root() actually trigger a heap GC? > > It certainly doesn't, but it obviously manipulates runtime > datastructures which may not necessarily be in a state during > finalization where this is safe. I'd have to study the runtime code > in detail to learn more, but maybe the OCaml team can clarify this > issue more quickly? I foresee absolutely no problems with registering/unregistering global roots from a C finalizer. As the manual states, the big no-no in C functions attached to custom blocks is allocating in the heap, either directly or via a callback into Caml or by releasing the global lock. Within a finalizer, you should also refrain from raising an exception, as this would leave the GC is a bizarre state. But global roots operations are OK. As for not using the CAMLparam, etc macros in these functions: since these functions must not allocate, the macros are certainly not needed. I don't think that actually using them could cause a problem, but that would be silly anyway, so don't use them in this context. Hope this answers your question. - Xavier Leroy