caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Ocaml Mailing List <caml-list@inria.fr>
Subject: [Caml-list] Why is struct caml_ba_proxy allocated outside the GC heap and why doesn't it have a finalizer?
Date: Sat, 1 Feb 2014 17:42:03 +0100	[thread overview]
Message-ID: <20140201164203.GG1783@frosties> (raw)

Hi,

in ZMQ (C library) I have zmq_msg_t structs that contain some metadata
(like the length) and potentially a pointer to data. For short
messages the data is part of zmq_msg_t and for larger it is allocated
seperately. The zmq_msg_t is an abstract type and I need to call
zmq_msg_close() when I no longer need that data of a message.

Now when I write bindings for this I would like to use Bigarray to
grant access to the data and there I run into a problem. I need to
call zmq_msg_close() when the Bigarray is freed by the GC. Normaly I
could use Gc.finalise to register a function that calls
zmq_msg_close(). But not so with Bigarray because they can be sliced.
The slicing creates a new Bigarray that points to the same data. The
data can only be freed when every Bigarray pointing to it is
unreachable. The way this works now in ocaml is using a struct
caml_ba_proxy.

The problem for me now is that the caml_ba_proxy is allocated outside
the GC heap and not reachable from the ocaml side. But I would have to
call Gc.finalise for the caml_ba_proxy object instead of the Bigarray.


Currently a Bigarray is a custom block that optionally contains a
pointer to the caml_ba_proxy. The pointer is set when a Bigarray is
sliced for the first time. And the caml_ba_proxy does reference
counting. A Bigarray also has a flag to say that the memory it points
to is not to be freed by the GC, is to be freed or is to be
munmap()ed, hardcoding 3 options.

I can see 3 possible improvements there:

1) add a "void (*free)(struct caml_ba_proxy *)" to the caml_ba_proxy
structure that, if not NULL, gets called when the caml_ba_proxy is
freed. In the case of GC managed memory this would be set to free the
memory. In the case of mmap it would be set to munmap. And in
unmanaged memory it would be NULL. And for C bindings using Bigarray
they can pass in their own free function pointer.

2) Like 1 but also add a "void *private". Additional state for the
Bigarray can be stored there. In my case a pointer to the zmq_msg_t
would be stored. Actually forget about 1 and just do 2.

3) Bigarray becomes a normal OCaml record and the caml_ba_proxy
becomes a custom block. The finaliser, compare, serialise, ...
functions of the Bigarray and some flags move to the caml_ba_proxy,
which is no longer optional. Reference counting gets dropped since the
GC already covers that better now and the Bigarray module adds a
function to add finalisers to the caml_ba_proxy object.


So what do you think? Would it make sense to patch ocaml to support
option 2 or 3?

MfG
	Goswin

             reply	other threads:[~2014-02-01 16:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01 16:42 Goswin von Brederlow [this message]
2014-02-01 20:49 ` Markus Mottl
2014-02-02  1:38   ` Goswin von Brederlow
2014-02-02  2:06     ` Markus Mottl
2014-02-04 15:32       ` Goswin von Brederlow

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=20140201164203.GG1783@frosties \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    /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;
as well as URLs for NNTP newsgroup(s).