Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] GC and file descriptors
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
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