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.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 1C457BC6B for ; Mon, 10 Dec 2007 12:25:05 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGSwXEfBMKMDh2dsb2JhbACPZAEBAQgKKQ X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="20163669" Received: from zenobe.lpn.cnrs.fr ([193.48.163.3]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 12:25:04 +0100 Received: from [10.8.0.81] (focu.lpn.prive [10.8.0.81]) by zenobe.lpn.cnrs.fr (Postfix) with ESMTP id 3913E524007 for ; Mon, 10 Dec 2007 12:25:04 +0100 (CET) Message-ID: <475D2210.70708@Lpn.cnrs.fr> Date: Mon, 10 Dec 2007 12:25:04 +0100 From: Fabrice Pardo User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version) References: <39980.81.57.198.61.1197236388.squirrel@webmail.lpn.cnrs.fr> <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com> In-Reply-To: <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; andrieu:01 descriptors:01 opendir:01 exn:01 exn:01 allocating:01 ocaml:01 deallocation:01 opendir:01 ocaml:01 allocating:01 wrote:01 unix:01 unix:01 heap:01 Olivier Andrieu wrote: > > Well, not really: a GC manages memory, not OS resources like file descriptors. > I wouldn't recommend relying on the GC to close those kind of resources. > > Write your code like this: > > let with_dir fname f = > let d = Unix.opendir f in > try let r = f d in Unix.closedir d ; r > with exn -> Unix.closedir d ; raise exn > > once the "f" function returns, you directory handle is closed. > > Thanks, this solution is clear and compact. I think that all functions allocating resources out of the OCaml heap should be documented as it, warning the programmer that he should not be lazy, relying on automatic deallocation of resources. The fact that Unix.opendir should be better documented in that sense is marginal for me. It was only an example of external C-allocated resource. When using these kind of external C functions, OCaml seems then less comfortable to the programmer than reference counted languages. The price to pay is not too high as functional code permit to encapsulate the problem as shown by Olivier. I have a new question now: What is the drawback if we keep hidden unsecure external functions (allocating out of the heap resources, as Unix.opendir), only publishing secure functions as "with_dir" ? Of course, I mean other drawback than changing the API. -- Fabrice