Re: [Caml-list] Using the C FFI to wrap an OCaml library

[Damien Doligez <damien.doligez@inria.fr>]

On 2008-02-09, at 05:07, Jonathan Bryant wrote:

> On Fri, Feb 8, 2008 at 4:53 PM, Joel Stanley <jstanley@galois.com>  
> wrote:
>
>> Well, much of my curiosity stems from the fact that I know little  
>> about
>> the OCaml runtime or how the OCaml GC is invoked.  If the GC can  
>> ever be
>> invoked in its own thread, it seems like while the values (of type
>> 'value') are being passed back on the stack (but *after* the
>> caml__local_roots pointer has been reverted) there could be problems?
>>
>> If this can't ever happen, great! Why not?
>
>
> I believe GC cycles can only be kicked off by an allocation since  
> this is the only time that any memory would need to be recovered, so  
> this could never happen.  As I understand it, any GC cycles would  
> start and complete within the call to the allocation function.

That is true, but there is a more fundamental reason.

> Multi threaded code might be an exception, because there could be a  
> context switch and a GC triggered by another thread at just the  
> wrong moment.


Even if the GC was concurrent, it would have to get the roots from the
worker thread's stack in an synchronous fashion, so it would be safe.


On 2008-02-08, at 22:53, Joel Stanley wrote:

> So let's talk about a concrete example here.  Let's say that I have  
> some
> dynamically-allocated object on the OCaml heap (for discussion  
> purposes,
> say it's an instance of some simple 'stack' class) and that I've
> returned a reference to that object to a C function.  Are you saying
> that the stack contents (e.g., a deep copy of my object) themselves  
> are
> marshaled across this boundary every time?

No, it's just a pointer, and if your C function allocates in the OCaml
heap, you'd better declare that pointer as a root and make sure you
reread it after each time it could have moved.

> What about, perhaps, having an object registration mechanism on the
> OCaml so that a newly-allocated object's reference goes into a  
> (global)
> hash table, and an opaque handle (e.g., some fresh, unique integer
> value) is yielded back to C land?  This would require an explicit
> deallocation (just passing the handle back) to come from the C side,  
> but
> should keep the heap object around until such a deallocation call is
> made.  Right?

This is pretty much what caml_register_global_root and
caml_remove_global_root do, except that the handle isn't opaque.

-- Damien