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=none 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 754AABC37 for ; Wed, 5 Aug 2009 17:04:51 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAAQ8eUqNGkAPkWdsb2JhbACaOQEBAQEJCwoHEwWqGgmQIQKCSYFNBQ X-IronPort-AV: E=Sophos;i="4.43,329,1246831200"; d="scan'208";a="44366538" Received: from deliver.uni-koblenz.de ([141.26.64.15]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 Aug 2009 17:04:51 +0200 Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 511FF78A12A0; Wed, 5 Aug 2009 17:04:50 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31431-06; Wed, 5 Aug 2009 17:04:49 +0200 (CEST) Received: from [141.26.71.237] (dhcp237.uni-koblenz.de [141.26.71.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 8F9A6789C2A5; Wed, 5 Aug 2009 17:04:49 +0200 (CEST) Message-ID: <4A799F89.6010001@uni-koblenz.de> Date: Wed, 05 Aug 2009 17:04:41 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_Pelzer?= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Damien Doligez Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Understanding GC and Alarms References: <4A783A0D.5080906@uni-koblenz.de> <1A0EB2E6-C9D8-478D-A266-806C5F74CA90@inria.fr> In-Reply-To: <1A0EB2E6-C9D8-478D-A266-806C5F74CA90@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Spam: no; 0.00; damien:01 damien:01 bug:01 bugfix:01 doligez:01 wrote:01 exception:01 exception:01 terminate:01 caml-list:01 functions:01 artificial:01 handler:03 finalise:04 finalise:04 Hello Damien! Damien Doligez wrote: > Yes, the GC calls the finalisation functions in order, so it waits for your > finalisation function to finish before starting the next one. If your > function doesn't terminate... > Ok, makes sense. >> Is there a way to get the GC back to normal after an exception during >> the alarm? > > That is the purpose of the Gc.finalise_release function: tell the GC to > behave > as if the current finalisation function had finished. Note that > finalise_release > is also safe to call from outside a finalisation function, so you can > call it > from your exception handler. Thank you very much! Very helpful, works as you say. In hindsight I should have figured this out from the manual, but, well, I didn't. :-) > When bug 4742 is fixed (probably in 3.12.0), you won't need it any more. > Note that I wanted to fix it by ignoring the exception entirely, but > your use case made me change my mind. Sounds good, keeping the exception handling would be useful, at least for me. Using the release-function as you explained is not much of a bother, in particular now that I get how it works, so there is no pressing need for a change/bugfix from my side. Thanks again and best regards, Björn -- Björn Pelzer AGKI - Artificial Intelligence Research Group University Koblenz-Landau, B 225 http://www.uni-koblenz.de/~bpelzer Tel.(office): (+49) 261 287 2776 Tel.(home): (+49) 261 942 3908