From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7CEF9OC008678
	for <caml-list@sympa-roc.inria.fr>; Fri, 12 Aug 2011 16:15:09 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am0BAHE0RU7RVdU2kGdsb2JhbABBp28IFAEBAQEJCQ0HFAQhgUABAQEBAgESAhMZARsdAQMBCwYFCzshAQERAQUBHAYTGweHTZxUCow2glWFAjuIbQIDBoZBBIdfizGJdYJiPIN8
X-IronPort-AV: E=Sophos;i="4.67,362,1309730400"; 
   d="scan'208";a="115680722"
Received: from mail-yw0-f54.google.com ([209.85.213.54])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Aug 2011 16:15:03 +0200
Received: by ywo32 with SMTP id 32so1456653ywo.27
        for <caml-list@inria.fr>; Fri, 12 Aug 2011 07:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        bh=6oQAGiIEU7PpWpeoxoipvlIgZLzI4spaFpSA5QQxIPA=;
        b=Nn1WbQJv/Gq2Hve+JZHDaSUupWY2Pix5tQIWARJXg+Iho3OkzQFxPuUTIuaPPuAY1S
         svlD/woRN3+Gy4mT4VLpuTPkNwAq8wC4RVvFulbdl1sj2v/3Ilaq39dX2GYFczoHtWN0
         LSYbza7RBPYj2XP68V+xn55pAjRRRhEIngq5I=
MIME-Version: 1.0
Received: by 10.142.225.6 with SMTP id x6mr477961wfg.55.1313158501963; Fri, 12
 Aug 2011 07:15:01 -0700 (PDT)
Received: by 10.68.47.131 with HTTP; Fri, 12 Aug 2011 07:15:01 -0700 (PDT)
In-Reply-To: <CAHR=VkzkSmhc-Op6Snf7E55whXWKnWGhjm2cd+RuoZv0Wouo-Q@mail.gmail.com>
References: <CAHR=VkzkSmhc-Op6Snf7E55whXWKnWGhjm2cd+RuoZv0Wouo-Q@mail.gmail.com>
Date: Fri, 12 Aug 2011 09:15:01 -0500
Message-ID: <CABWZ6OSnEUsCoAV9=BzEbtmAinoKT+Jff8-ey2vmFc9eo5zi0A@mail.gmail.com>
From: Romain Beauxis <romain.beauxis@gmail.com>
To: Thomas Braibant <thomas.braibant@gmail.com>
Cc: caml-list@inria.fr
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p7CEF9OC008678
Subject: Re: [Caml-list] C bindings: memory managment

2011/8/12 Thomas Braibant <thomas.braibant@gmail.com>:
> Hi,

Hi!

> During  my summer vacations, I decided to have fun trying to make an
> OCaml binding for a C library (my first time). My requirements were to
> have an "OCaml feeling" (i.e. to have an OCaml interface that looks
> like the library was written in OCaml), and to have good memory
> management (no leaks).
>
> Following the manual, it was easy to get a working binding for a
> subset of the library (enough to follow the tutorial of the given
> library). However, I ended up bitten by a nasty problem.
>
> The OCaml interface looks like this (this is a 2D physic library) :
>
> module Body : sig
> type t (* == body* *)
> val make : ... -> t
> end
>
> module Space : sig
> type t (* == space* *)
> val make : unit -> t
> val add_body : t -> Body.t -> unit
> val step : t -> unit
> end
>
> On the C side, Space.make and Body.make correspond to functions that
> allocates custom blocks that hold space* and body* (the finalizers of
> these custom blocks correspond to the relevant free-ing functions in
> C).
>
> However, this is wrong, since with the following piece of code, the GC
> has the right to remove the bodies once in the loop (there is no more
> reference to them). I end up with a segmentation fault.
>
> let body1 = Body.make ... in
> let body2 = Body.make ... in
> let space = Space.make () in
> let _ = Space.add_body space body1 in
> let _ = Space.add_body space body2 in
> for i = 0 to ... do
>   Space.step space
> done;;
>
> This bodies are not global roots (as far as I understand the
> terminology), so I do not see a way to tell the GC not to free the
> bodies while there is still a reference to the space they have been
> added to. At least, I see no such thing in the documentation.
>
> The solutions I can imagine are:
> - either to define Space.t as a record/tuple that contains a space*
> and an OCaml list of the bodies that have been added. This seems a bit
> of a duplication of the underlying C library.

This is the solution I go for when there is strong necessity for the
user to control close/collection by himself, i.e. when the ressource
is not a file or something similar.. Otherwise, I use your third
option below..

> - either to use some reference counting and memory management as an
> interface between the target C library, and the OCaml library.
> -  either to require the user to use a "free" OCaml function to do the
> memory management (this does not meet my requirements, but this is how
> my target C library is binded in other functional languages...).


Romain