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=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 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 DB5AABC37 for ; Fri, 1 May 2009 18:00:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0EAJu5+klIDtyckGdsb2JhbACDAJMnPwEBAQEJCQwHEQOnO4EIkAoBAwEDg3oFh3Y X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="28604160" Received: from fg-out-1718.google.com ([72.14.220.156]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 May 2009 18:00:57 +0200 Received: by fg-out-1718.google.com with SMTP id e12so769016fga.20 for ; Fri, 01 May 2009 09:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3gt7W05ZehMWpryYNJ7YkJMnwqXfKf1/G8TCwE2GpTk=; b=F/1PXUJtu2eIDwmws2wmBqG4Yvs017brqdhBH2BsLFA0IYH+MwZ93Kb5mbQcqF5b06 exM361Cv8xuFgrPzle1GsseBh3p3jU42D/yhDcv5dNdn7so/bQvh8yG8W393qcUVc16y bWSizwDkn/6z+cmmmVXnbAbKjS/28wYkN6Nm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DqnWAoz5cP/zmKYwYn5KA39pDtUOyO985r7U405Hc35VdgqdZf4survI/kJgHjxMhu rJiMnl9hhBjib+PEw/LnSQmE3c9YdStscE1sbNABGSrF65cqBtevM5vllEW14GsV9+ml 73nBLm+UiVdZnlIbpsLGPHsJ6QBggsUjYL1Uw= MIME-Version: 1.0 Received: by 10.86.90.2 with SMTP id n2mr2991974fgb.61.1241193657075; Fri, 01 May 2009 09:00:57 -0700 (PDT) In-Reply-To: <49FB04A9.3090008@soton.ac.uk> References: <49FB04A9.3090008@soton.ac.uk> Date: Fri, 1 May 2009 12:00:56 -0400 Message-ID: Subject: Re: [Caml-list] Custom blocks and finalization From: Markus Mottl To: "Dr. Thomas Fischbacher" Cc: OCaml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 ocaml:01 pointers:01 ocaml-value:01 ocaml:01 runtime:01 finalizers:01 runtime:01 finalizer:01 2009:98 caml-list:01 functions:01 On Fri, May 1, 2009 at 10:18, Dr. Thomas Fischbacher > Can you provide some more information on the low level > details about this issue? E.g. can it arise in non-threaded > OCaml code? Yes, if your C-finalizer e.g. needs to remove global roots, this may not be sound. I am not totally sure this is actually true in the current implementation, but at least the documentation clearly indicates that any interaction with the OCaml-runtime from within C-finalizers is prohibited. You may essentially just extract C-values / pointers from the OCaml-value to be reclaimed and manipulate those. > If there is any way to get this resolved by e.g. introducing > another set of C-level functions within OCaml and asking > people to switch over to using those, I would consider > that the most appropriate way forward. It's my superficial impression that the runtime system could be fixed such that interactions with it from within C-finalizers and other custom functions becomes safe, maybe at the expense of some performance. E.g. if you register finalizers with the Gc-module from within OCaml, it seems that the runtime first records all finalizer functions that need to be called after a collection in a table. Maybe something similar can be done for C-finalizers? Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com