From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 2ED19BC37 for ; Wed, 10 Feb 2010 22:37:55 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBAH+2ckvZSMDdkGdsb2JhbACaZhUBAQEBCQkMBxMDIL40hFUE X-IronPort-AV: E=Sophos;i="4.49,446,1262559600"; d="scan'208";a="52436832" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 Feb 2010 22:37:54 +0100 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate01.web.de (Postfix) with ESMTP id A3EAD146AA1C2; Wed, 10 Feb 2010 22:37:54 +0100 (CET) Received: from [95.208.117.111] (helo=frosties.localdomain) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NfKFu-0000gh-00; Wed, 10 Feb 2010 22:37:54 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1NfKFt-0004u5-Un; Wed, 10 Feb 2010 22:37:54 +0100 From: Goswin von Brederlow To: Rich Neswold Cc: Goswin von Brederlow , caml-list@inria.fr Subject: Re: [Caml-list] Preventing values from escaping a context References: <14cf844b1002081907y2900c313q97ae0cb6f4c92394@mail.gmail.com> <20100209.123813.39168535.garrigue@math.nagoya-u.ac.jp> <4B711D44.7040509@irisa.fr> <14cf844b1002091009p1a3181j793c2d6b2cdcbae5@mail.gmail.com> <4B71AD39.8020503@irisa.fr> <14cf844b1002091639q5641977evc2101f72c80bd10d@mail.gmail.com> <871vgto4gd.fsf@frosties.localdomain> <14cf844b1002101000p2737c63yd311be691c9661b1@mail.gmail.com> Date: Wed, 10 Feb 2010 22:37:53 +0100 In-Reply-To: <14cf844b1002101000p2737c63yd311be691c9661b1@mail.gmail.com> (Rich Neswold's message of "Wed, 10 Feb 2010 12:00:30 -0600") Message-ID: <87hbposrf2.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX19fyBTIbB6e9M1ThMol7/KlqtteW3JRT7K4eUE5 utAHhHVS2aGgQgGU85v9V4RvDpvn4WC9/6rfPOI3S5E//QnprJ OL7JdP7IU= X-Spam: no; 0.00; finalizer:01 finalizer:01 escapes:01 rewriting:01 10,:98 belt:98 mfg:98 wrote:01 unix:01 exception:01 caml-list:01 int:01 int:01 writes:01 api:02 Rich Neswold writes: > On Wed, Feb 10, 2010 at 2:55 AM, Goswin von Brederlow > wrote: > > Why not make the context a custom block with finalizer? The finalizer > then frees the resources. If the context escapes then it remains alive > and the finalizer will not be called any time soon. Only when it is no > longer reachable. That would also allow someone to create a context > and use it for a number of operations before forgeting it. > > > Good point. I'll need to consider this as a possible API direction. I have many > years of C/C++ programming under my belt, so I tend to want to micromanage the > resources. :) As an example I have done this while rewriting Unix.file_descr for myself. My FD is a custom block containing the int. MyUnix.close will set the int to -1 to signal the FD is no longer valid. MyUnix.read / write / ... throw an exception when the FD is -1. And the finalizer outputs a warning and closes the FD unless it is -1. That way I can close FDs when I want them closed and I can not leak an unclosed FD (although you can still keep it alive forever). I also get a warning when I forget to close an FD either soon after it dies or at the end of the program if it was kept alive forever. MfG Goswin