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.1 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 CB2FABC37 for ; Wed, 5 Aug 2009 16:33:47 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,328,1246831200"; d="scan'208";a="44365414" Received: from 250-99.msr-inria.inria.fr (HELO [10.0.1.2]) ([193.55.250.99]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 05 Aug 2009 16:33:47 +0200 Cc: caml-list@yquem.inria.fr Message-Id: <1A0EB2E6-C9D8-478D-A266-806C5F74CA90@inria.fr> From: Damien Doligez To: =?ISO-8859-1?Q?Bj=F6rn_Pelzer?= In-Reply-To: <4A783A0D.5080906@uni-koblenz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [Caml-list] Understanding GC and Alarms Date: Wed, 5 Aug 2009 16:33:47 +0200 References: <4A783A0D.5080906@uni-koblenz.de> X-Mailer: Apple Mail (2.935.3) X-Spam: no; 0.00; damien:01 damien:01 bug:01 bug:01 2009:98 doligez:01 doligez:01 wrote:01 exception:01 exception:01 terminate:01 caml-list:01 functions:01 functions:01 caml:02 Hello, On 2009-08-04, at 15:39, Bj=F6rn Pelzer wrote: > With the alarm loop, the GC will only print the first part ("Calling =20= > finalisation functions.") once at the start of the loop and then =20 > begin looping, starting new cycles but no new finalisations. Yes, the GC calls the finalisation functions in order, so it waits for =20= your finalisation function to finish before starting the next one. If your function doesn't terminate... > The other (and to me more severe) oddity is that if the alarm =20 > function raises an exception, then the GC seems to remain in its =20 > "special mode" where it starts no finalisation calling - but now it =20= > will also refuse to do any alarms. Yes, that is the essence of bug report 4742: < http://caml.inria.fr/mantis/view.php?id=3D4742 > > Is there a way to get the GC back to normal after an exception =20 > during the alarm? That is the purpose of the Gc.finalise_release function: tell the GC =20 to behave as if the current finalisation function had finished. Note that =20 finalise_release is also safe to call from outside a finalisation function, so you can =20= call it from your exception handler. 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. -- Damien