Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
exception safety / RAII ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-03-09 (01:21)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: Re: exception safety / RAII ?
On Tuesday 08 March 2005 22:53, Daniel Yokomizo wrote:
> "Jon Harrop" <> escreveu na mensagem
> > Ok, I have found that, with a little thought and careful design
> > beforehand, 
> > this is not a problem in OCaml. In the case of DAG dependency graphs, my
> > solution is to represent the dependency graph for the GC by maintaining a
> > list of references to dependees in each object. This forces the GC to
> > respect 
> > dependencies when collecting.
> AFAIK it doesn't force the GC to respect the dependencies. An object is 
> garbage if it can't be reached from any root references, it doesn't matter
> if other garbage objects still reference it.

Yes, thank you for the more formal description. :-)

Provided people want exactly this behaviour (which I do) then I believe that 
the approach I am using will work. You are quite right that this only 
respects dependencies between live objects and not between garbage objects.

I haven't come across any tasks which require more sophisticated GC trickery, 
but I've no doubt that such tasks exist. I can't think of a good general 
solution which doesn't basically require you to implement your own GC in 
OCaml (weak pointers, incremental etc.).

> IIUC the current OCaml GC implementation may exhibit such properties (i.e.
> respect dependencies) but it isn't required to do so.

Yes, the current GC may happen to deallocate things in the reverse of the 
order they were allocated in (this would explain why some things currently 
happen to work) but I've no idea if this really is the case.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists