Re: [Caml-list] The OCaml garbage collector, finalisers, and the right way of disposing native pointers in C bindings

["Kim Nguyễn" <Kim.Nguyen@lri.fr>]

Hi,

On Tue, Jan 12, 2016 at 10:12 AM, Neuhaeusser, Martin
<martin.neuhaeusser@siemens.com> wrote:
> Dear all,
>
> I assume this is a common problem in writing interfaces to C libraries. If so, is there a preferred way how to tackle it?
> Two approaches that came to my mind are
>
> 1. One could design the C-stubs such that they accept values of type ocaml_record and extract the native pointer within the C stub. In the C-stubs, the GC must not collect an item that has been "pinned" by the CAMLparamX macros, right?

That would work but in that case, the approach I prefer is to put the
native pointer in a custom block. This way you can attach your
finalizer (written in C) directly to the block and it will be called
when the (wraped) pointer itself is reclaimed. This also allows you to
fine tune the behaviour of the GC w.r.t. the use you make of such
pointers. Of course, one orthogonal problem is that if you create two
custom blocks with the same pointer inside, you must implement some
other mechanism to avoid double frees (like refcounting or something).
But this is a problem you already have with your OCaml record approach
(if two distinct records can hold the same native_ptr, then the
finalizer might get called twice). The advantage of custom blocks is
then that they are self sufficient and you can put such objects in
other data-structures (e.g. for debugging purposes). But indeed your C
bindings will need to extract the pointer from the custom block and
since they are given a heap allocated OCaml value (the custom block)
it will need to be protected bu CAMLparam macros. This also might make
your code more future-proof since it seems that at some point (just
from reading this mailing list) there will be (is ?) a version of the
OCaml runtime where naked pointer are forbidden on the heap (unless
they are wrapped in a custom block).


> 2. One could invent some function that takes an ocaml_record, but does nothing with it and whose calls do not get optimized away by the compiler... Evaluating such a function after the call to NativeLib.native_function would prevent the GC from collecting ocaml_record. However, this feels like a very ugly hack.

Very ugly indeed. And the OCaml compiler is getting better and better
at inlining stuff so it's quite hard to predict what is inlined and
what isn't (unless you write some "obviously" inefficient code that
has no chance what so ever to be inlined … but sill).

Cheers,
--
Kim