From guillaume.yziquel at citycable.ch  Sun Nov 29 01:50:38 2009
From: guillaume.yziquel at citycable.ch (Guillaume Yziquel)
Date: Sun, 29 Nov 2009 01:50:38 +0100
Subject: [Rd] PROTECT and OCaml GC.
In-Reply-To: <8ec76080911281625q5d5b8824hefb14af9b23d29f0@mail.gmail.com>
References: <4B11B75C.9070806@citycable.ch>
	<8ec76080911281625q5d5b8824hefb14af9b23d29f0@mail.gmail.com>
Message-ID: <4B11C55E.2060909@citycable.ch>

Whit Armstrong a ?crit :
> I've had success w/ using a reference counting paradigm in which the outside
> memory manager calls UNPROTECT_PTR(R_object_); in its destructor.
> 
> So, in my case (using c++ ) if objects are allocated on the heap, which
> allocate R objects as their backend storage, I don't have to worry about out
> of order UNPROTECT calls b/c UNPROTECT_PTR will just put the objects that
> c++ destroys on the gc list.
> 
> If you are using c as the glue for all your ocaml bindings, they you may
> want to have a look at this:
> http://github.com/armstrtw/rabstraction
> 
> Or the in progress re-write here: http://github.com/armstrtw/RObjects
> 
> -Whit

Thanks a lot for these pointers.

UNPROTECT_PTR seems quite interesting. As I understand it, it avoids 
caring about protecting and unprotecting in the order the stacks would 
expect. This is quite interesting, since I'd like to keep OCaml's GC to 
do housekeeping, and not rely on referencing counting.

I'm using C as the glue, but I want it to be as thin as possible. I will 
probably not do reference counting in C, for instance. Nevertheless, 
there's obviously good ideas in rabstraction/RObjects that I'll adapt.

Thanks a lot.

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/



[Rd] PROTECT and OCaml GC.
Guillaume Yziquel