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 TAA23344; Sat, 15 Nov 2003 19:31:52 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA23200 for ; Sat, 15 Nov 2003 19:31:51 +0100 (MET) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hAFIVm120303; Sat, 15 Nov 2003 19:31:48 +0100 (MET) Received: from 203-213-83-146-syd-ts15-2600.tpgi.com.au (203-213-83-146-syd-ts15-2600.tpgi.com.au [203.213.83.146]) by mail2.tpgi.com.au (8.12.10/8.12.10) with ESMTP id hAFIVWEU013779; Sun, 16 Nov 2003 05:31:34 +1100 Subject: Re: [Caml-list] GC and file descriptors From: skaller Reply-To: skaller@ozemail.com.au To: Ville-Pertti Keinonen Cc: Dustin Sallings , Damien Doligez , Caml Mailing List In-Reply-To: <20031115155617.GA592@exomi.com> References: <70D8AC5D-16A8-11D8-BFCA-00039310CAE8@inria.fr> <4A73AF35-16D1-11D8-9BF4-000393CFE6B8@spy.net> <1068905767.25869.130.camel@pelican> <20031115155617.GA592@exomi.com> Content-Type: text/plain Message-Id: <1068917444.25869.244.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 16 Nov 2003 04:30:46 +1100 Content-Transfer-Encoding: 7bit X-Kaspersky-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 1100,:01 orderly:01 python:01 finalization:01 python:01 python's:01 interscript:01 orderly:01 stackless:01 anyhow:01 ocaml:01 ocaml:01 garbage:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2003-11-16 at 02:56, Ville-Pertti Keinonen wrote: > On Sun, Nov 16, 2003 at 01:16:08AM +1100, skaller wrote: > > > It is possible to modify the Ocaml collector to make finalisation > > orderly, but it is very expensive. It is also possible > > Not just expensive, more like something you definitely don't want to > even try. Python tries to have deterministic finalization, but > falls back on "normal" garbage collection for containers Funny, but I actually *needed* deterministic finalisation. And the reason was .. I was implementing a Python interpreter in Ocaml, and needed to emulate Python's ref counting. But I didn't want to actually do any ref counting :-) Because of this problem, my own major Python program interscript would not run on my interpreter, since it relied on orderly finalisation. The reason for *that* is that it effectively executed commands written by the client, and the specification provided for opening and writing to files, but not for closing them. Closing files was important and had to be correctly timed: for example, closing the main document actually generated the table of contents (since only at the end are all the contents known). Anyhow .. there do exist cases where explicit finalisation is difficult. This was one of them (and was one of the main reasons I abandoned the project -- lack of support for stackless operation was the other). ------------------- 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