From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA15507; Fri, 14 Nov 2003 21:55:20 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA15769 for ; Fri, 14 Nov 2003 21:55:19 +0100 (MET) Received: from moby.atcorp.com (moby.atcorp.com [204.72.172.2]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAEKtH101208 for ; Fri, 14 Nov 2003 21:55:18 +0100 (MET) Received: from atcorp.com (seahorse.atcorp.com [204.72.172.13]) by moby.atcorp.com (8.11.6/8.11.2) with ESMTP id hAEKvsZ26181 for ; Fri, 14 Nov 2003 14:57:54 -0600 Message-ID: <3FB5410F.8090008@atcorp.com> Date: Fri, 14 Nov 2003 14:54:39 -0600 From: Eric Dahlman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] GC and file descriptors References: <70D8AC5D-16A8-11D8-BFCA-00039310CAE8@inria.fr> <3FB4ED56.6020804@univ-savoie.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 raffalli:01 raffalli:01 univ-savoie:01 subprocesses:01 christophe:01 christophe:01 profile:98 garbage:01 garbage:01 dmitry:01 descriptors:01 descriptors:01 writes:01 bely:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Dmitry Bely wrote: > Christophe Raffalli writes: > > >>>> Garbage collecting the subprocesses and file descriptors would >>>>make this a bit more straightforward. >>> >>>The problem with this approach is that the "close" and "wait" >>>system calls have side effects. I don't like the idea of a GC >>>that has side effects other than the memory size of the program >>>(and finalisation functions, of course). >> >>Why ? Could you elaborate ? > > close() can fail (generate an exception). How are you going to handle it in > the garbage collector? On the contrary, the memory deallocaton always > succeeds. Another problem with doing this is that you are tying the rate at which file descriptors are closed to the GC profile of your program. If you only have 10's or 100's of file descriptors available it would be very easy to use them all up in a tight loop which did not allocate much memory. It would be a bummer to have your program start failing because you used a more memory efficient algorithm for some calculation. -Eric ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners