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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 43B2BBC57 for ; Sat, 20 Nov 2010 21:33:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkCAA6/50zZSMDjgmdsb2JhbACiZRUBAQsLCAcTAx+6H4VLBI1s X-IronPort-AV: E=Sophos;i="4.59,229,1288566000"; d="scan'208";a="79741319" Received: from fmmailgate02.web.de ([217.72.192.227]) by mail4-smtp-sop.national.inria.fr with ESMTP; 20 Nov 2010 21:33:06 +0100 Received: from smtp02.web.de ( [172.20.0.184]) by fmmailgate02.web.de (Postfix) with ESMTP id 3F1FB18544B01; Sat, 20 Nov 2010 21:32:37 +0100 (CET) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp02.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #24) id 1PJu6v-00082v-00; Sat, 20 Nov 2010 21:32:37 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.72) (envelope-from ) id 1PJu6u-0007Qh-GD; Sat, 20 Nov 2010 21:32:36 +0100 From: Goswin von Brederlow To: Sylvain Le Gall Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Looking for stubs for sendmsg/recvmsg References: <87d3q21qe4.fsf@frosties.localnet> <87ipztl2ld.fsf@frosties.localnet> <8739qx88e9.fsf@frosties.localnet> Date: Sat, 20 Nov 2010 21:32:35 +0100 In-Reply-To: (Sylvain Le Gall's message of "Fri, 19 Nov 2010 22:10:55 +0000 (UTC)") Message-ID: <87lj4n3fdo.fsf@frosties.localnet> 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=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1+WJh0CL6qVY72KJ1s5jen9NlbdpYkNKsU3IW34 bsG0u7ot/YAtfsDoEuDPxb4Z+R+PYE2QcxUnhVMJuitJ1dA+4Z DIzgvpZ5E= X-Spam: no; 0.00; stubs:01 le-gall:01 le-gall:01 finalizer:01 leaking:01 mfg:98 terminates:01 wrote:01 wrote:01 unix:01 unix:01 caml-list:01 functions:01 precisely:01 writes:01 Sylvain Le Gall writes: > On 19-11-2010, Goswin von Brederlow wrote: >> Sylvain Le Gall writes: >>> On 19-11-2010, Goswin von Brederlow wrote: >>>> Sylvain Le Gall writes: >>>>> On 18-11-2010, Goswin von Brederlow wrote: >>> >>> Not that much, if you proceed in another way. I think what you are >>> looking for is a fd leak detector? >>> >>> Here is a small modules that I have written for this purpose: >>> >>> File UnixExt.ml: >>> (** Count open/close call *) > > [...] > >>> [...override other functions that open/close fd...] >>> >>> Then in the modules using this features, you just have to open UnixExt >>> after Unix... >>> >>> You can even probably design a library that will transparently hide Unix >>> with a custom Unix module providing this feature. >> >> Much less usefull. >> >> Using a custom block with finalizer means that the FD will be closed >> relative close to where/when it was leaked. Makes it easier to find >> where it was leaked and adding GC.compact calls at strategic locations >> can narrow it down even more. Leaking FDs also becomes much less >> serious. The GC will clean them up and close them. So you can use an app >> that leaks FDs just fine. >> > > It all depends on what you want: fix your program that leaks or live > with it. The former piece of code helps to fail if there are leaked FD. > On Unix FD leaks is not that problematic, but on Windows it turns to be > another problem. > > The best example about this: you cannot delete a file that has an FD > still open on it. This makes harder to remove temporary file (and this > piece of code was precisely made to track FD on temporary files, that > let 1000s of unremoved temp file). > > Regards, > Sylvain Le Gall Which again speaks for my solution. The leaked FD will be closed much faster (before the program terminates) and one can remove the tempfiles while the program is still running. MfG Goswin