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 QAA15549; Sat, 15 Nov 2003 16:17:06 +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 QAA16385 for ; Sat, 15 Nov 2003 16:17:05 +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 hAFFH2102477; Sat, 15 Nov 2003 16:17:03 +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 hAFFGskX022246; Sun, 16 Nov 2003 02:16:58 +1100 Subject: Re: [Caml-list] GC and file descriptors From: skaller Reply-To: skaller@ozemail.com.au To: Dustin Sallings Cc: Damien Doligez , Caml Mailing List In-Reply-To: <4A73AF35-16D1-11D8-9BF4-000393CFE6B8@spy.net> References: <70D8AC5D-16A8-11D8-BFCA-00039310CAE8@inria.fr> <4A73AF35-16D1-11D8-9BF4-000393CFE6B8@spy.net> Content-Type: text/plain Message-Id: <1068905767.25869.130.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 16 Nov 2003 01:16:08 +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 conceptually:01 finalization:01 abstraction:01 entails:01 orderly:01 orderly:01 fifo:01 lablgtk:01 gui:01 python:01 reflection:01 gui:01 anyhow:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2003-11-15 at 05:35, Dustin Sallings wrote: > close() seems to be conceptually the same finalization as free() to > me. It releases a system resource back to the process that would > otherwise be unavailable forever. This isn't the case though. The problem is that system resources *other than memory* are represented in memory. So finalising the memory/executing a destructor causes releasing the resource *other than memory* by way of the memory representation, but memory itself is released directly by the gc -- no need to delete what a pointer in memory points to in a destructor, and indeed unsafe in most cases. In other words .. finalisation functions may be part of the abstraction which a representation of a system resource in memory entails, but collectable memory is not such a resource, even though it has such a representation (a pointer): memory is not abstract but concrete. Please can someone say this better? Anyhow, RAII (Resource Acquisition Is Initialisation) paradigm popular in C++ requires synchronous and orderly destruction which garbage collectors do not usually provide. Here synchronous means an object is destroyed *immediately* there are no reference to it, and orderly means in order of dependency (usually FIFO). It is possible to modify the Ocaml collector to make finalisation orderly, but it is very expensive. It is also possible to synchonise finalisation with explicit calls to the gc, although that isn't quite the same as synchronous destruction. Its easier, usually, to just explicitly release a resource. By the way I'm curious: in LablGTK, there will be finalisation functions for releasing GTK resources, since GTK also has them (Yes?) It isn't clear this will work in general, since the finalisation is neither synchronous nor orderly.. but both are required in general in a GUI. Python has this problem with Tkinter, which opens and creates things fine, but cannot handle release correctly -- this is because two way reflection is the only way to make that work (and it is *very* difficult to get right) It's a real pain, when you use foreign representations of GUI objects, and the GUI simply isn't strong enough in terms of notifications. ------------------- 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