Browse thread
[Caml-list] GC and file descriptors
-
Dustin Sallings
- David Fox
- Nicolas George
- Mikael Brockman
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2003-11-15 (15:17) |
From: | skaller <skaller@o...> |
Subject: | Re: [Caml-list] GC and file descriptors |
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