From: Romain Beauxis <romain.beauxis@gmail.com>
To: Thomas Braibant <thomas.braibant@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] C bindings: memory managment
Date: Fri, 12 Aug 2011 09:15:01 -0500 [thread overview]
Message-ID: <CABWZ6OSnEUsCoAV9=BzEbtmAinoKT+Jff8-ey2vmFc9eo5zi0A@mail.gmail.com> (raw)
In-Reply-To: <CAHR=VkzkSmhc-Op6Snf7E55whXWKnWGhjm2cd+RuoZv0Wouo-Q@mail.gmail.com>
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
next prev parent reply other threads:[~2011-08-12 14:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-12 10:10 Thomas Braibant
2011-08-12 10:56 ` David Allsopp
2011-08-12 14:15 ` Romain Beauxis [this message]
2011-08-13 14:40 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABWZ6OSnEUsCoAV9=BzEbtmAinoKT+Jff8-ey2vmFc9eo5zi0A@mail.gmail.com' \
--to=romain.beauxis@gmail.com \
--cc=caml-list@inria.fr \
--cc=thomas.braibant@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox