From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D28AF7F7B4 for ; Sat, 1 Feb 2014 21:49:56 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.216.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.216.171 as permitted sender) identity=mailfrom; client-ip=209.85.216.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qc0-f171.google.com) identity=helo; client-ip=209.85.216.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-qc0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksCAMZc7VLRVdirlGdsb2JhbABYg0RXqhmTSIEACBYOAQEBAQcLCwkSKoIlAQEFQAEUBxILAQMMBgULDQ0WCyEBAREBBQEKEgYTEodeAQMRDZ9MjFyDCZMvChknAwoVT4hPEQEFDIxnghYHhDgEiUmMdYFsgTKJHYIPg1YYKYMbgVwe X-IPAS-Result: AksCAMZc7VLRVdirlGdsb2JhbABYg0RXqhmTSIEACBYOAQEBAQcLCwkSKoIlAQEFQAEUBxILAQMMBgULDQ0WCyEBAREBBQEKEgYTEodeAQMRDZ9MjFyDCZMvChknAwoVT4hPEQEFDIxnghYHhDgEiUmMdYFsgTKJHYIPg1YYKYMbgVwe X-IronPort-AV: E=Sophos;i="4.95,760,1384297200"; d="scan'208";a="56445095" Received: from mail-qc0-f171.google.com ([209.85.216.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 01 Feb 2014 21:49:56 +0100 Received: by mail-qc0-f171.google.com with SMTP id n7so9236337qcx.30 for ; Sat, 01 Feb 2014 12:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZurhvwQHYfnXNVV39dKp8FQ0mrIErfAvHrNwXgcvZIQ=; b=F4BlhzbOLJmT9urQvyZzBsfw3KDuU9Ihh+/zvQZbCG6Hde/2/qSTiLEsqLxS0MSH2m w4fvbcNgP8fYg2pykJkM0w4qf/InRIgrkYNZTaU1tPVrvqyPFusmczti3X0ffQ4Wxug/ Wti9/37DvEf4Dx8eJ+IuE7zcizhBvZFoFWooptdcWdb8ZUuHdhUx94g8djj1ew/vxALg 9FaxMo4N+KEDusIVWSgHmBXcia4LZinpcX27E5zHcUxDlDi6gNOT5g4Sb4JWIuPFkS66 Iv1c+splzwSF8W/PgkqNqHjOsUQ7F9rjeOFCQ8QiHiCM7hSKqI6i+RVrCNpcRJCAeLdT FEtQ== MIME-Version: 1.0 X-Received: by 10.224.55.197 with SMTP id v5mr43673263qag.9.1391287795357; Sat, 01 Feb 2014 12:49:55 -0800 (PST) Received: by 10.140.90.70 with HTTP; Sat, 1 Feb 2014 12:49:55 -0800 (PST) In-Reply-To: <20140201164203.GG1783@frosties> References: <20140201164203.GG1783@frosties> Date: Sat, 1 Feb 2014 15:49:55 -0500 Message-ID: From: Markus Mottl To: Goswin von Brederlow Cc: Ocaml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Why is struct caml_ba_proxy allocated outside the GC heap and why doesn't it have a finalizer? I'd opt for 2). 1) seems problematic, e.g. what if several functions from possibly independent libraries needed to be executed? 2) would allow you to store a previous function pointer and the old contents of the private field in the new private field so you can "chain" finalization calls. This would also work seamlessly with "free" and "munmap". 3) would seem less efficient. Storing pointers to C-data in a normal record could cause troubles with the GC so you might have to store another unscanned abstract/custom block in the record, adding another layer of indirection. Regards, Markus On Sat, Feb 1, 2014 at 11:42 AM, Goswin von Brederlow wrote: > 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 > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com