From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C444BBC32 for ; Tue, 8 Mar 2005 13:32:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j28CWCkJ012535 for ; Tue, 8 Mar 2005 13:32:12 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA01472 for ; Tue, 8 Mar 2005 13:32:12 +0100 (MET) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j28CWBhM012530 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 8 Mar 2005 13:32:11 +0100 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1D8dsh-0001J9-00 for ; Tue, 08 Mar 2005 12:32:11 +0000 Date: Tue, 8 Mar 2005 12:32:11 +0000 To: caml-list@inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII ? Message-ID: <20050308123210.GA4997@furbychan.cocan.org> References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071330.49084.jon@jdh30.plus.com> <877e9a170503070721b2e0298@mail.gmail.com> <200503071729.20117.jon@jdh30.plus.com> <877e9a1705030710476502ad31@mail.gmail.com> <1110281592.680.102.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110281592.680.102.camel@localhost> User-Agent: Mutt/1.3.28i From: Richard Jones X-Miltered: at concorde with ID 422D9B4C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 422D9B4B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 imho:01 garbage:01 sockets:01 non-trivial:01 val:01 notepad:01 ...:98 wrote:01 exception:01 scope:01 finalization:01 descriptor:02 thread:02 variables:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Tue, Mar 08, 2005 at 01:33:12PM +0200, Ville-Pertti Keinonen wrote: > IMHO currently the closest to the "best of both worlds" is a good > garbage collector (with non-deterministic finalization) and explicit > management for those resources that need them (file handles are a good > example; in addition to the reasons already mentioned in this thread, > also because they may refer to sockets and to avoid running into file > descriptor limits). I think it'd be nice to have both finalisation and destructors when a local variable goes out of scope. You might need to mark variables specially to indicate that those (and only those) should be reference counted. I understand that the implementation would be non-trivial. Perhaps: val open_in : string -> in_channel refcounted There was a great paper I read about a year ago all about how finalisation and destruction are completely separate concepts. Unfortunately I can't find it now ... Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Team Notepad - intranets and extranets for business - http://team-notepad.com