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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id E2F707FDC9 for ; Tue, 12 Jan 2016 10:38:24 +0100 (CET) IronPort-PHdr: 9a23:ANGZjxLBprqpIGLiK9mcpTZWNBhigK39O0sv0rFitYgUI/zxwZ3uMQTl6Ol3ixeRBMOAu6wC27Cd4/iocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0YLnjavio9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4FPlQBaP73YBSX4biF4AJgHf8BD8FN+ltyLgqut7ni+XIM3/QK0vQjm4x7xqRRrljjxBPDk8pjL5kMt12YFapVqHqAFuQYicNKKUMbxYcb7McNUyQXBAGMhLAX8SSrigZpcCWrJSdd1TqJPw8h5X9UOz Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=Kim.Nguyen@lri.fr; spf=None smtp.mailfrom=Kim.Nguyen@lri.fr; spf=None smtp.helo=postmaster@mx2.u-psud.fr Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Kim.Nguyen@lri.fr) identity=pra; client-ip=129.175.212.65; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Kim.Nguyen@lri.fr"; x-sender="Kim.Nguyen@lri.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Kim.Nguyen@lri.fr) identity=mailfrom; client-ip=129.175.212.65; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Kim.Nguyen@lri.fr"; x-sender="Kim.Nguyen@lri.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mx2.u-psud.fr) identity=helo; client-ip=129.175.212.65; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Kim.Nguyen@lri.fr"; x-sender="postmaster@mx2.u-psud.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AABAyZRWnEHUr4FehDhBBohTtSOGDwKBHAc8EAEBAQEBAQEBEAEBAQEBCAsJCSEugi2CBwEBAQMBI0sLBQsLCw0CAh8HAgIiEwUdBhOIJggFrzWQKQEBAQEGAQEBAQEegQGKVIRVgx+BSQEElxONWYFeh0qFVIpggjiBOQI5glEkgUFxhjEBAQE X-IPAS-Result: A0D7AABAyZRWnEHUr4FehDhBBohTtSOGDwKBHAc8EAEBAQEBAQEBEAEBAQEBCAsJCSEugi2CBwEBAQMBI0sLBQsLCw0CAh8HAgIiEwUdBhOIJggFrzWQKQEBAQEGAQEBAQEegQGKVIRVgx+BSQEElxONWYFeh0qFVIpggjiBOQI5glEkgUFxhjEBAQE X-IronPort-AV: E=Sophos;i="5.20,556,1444687200"; d="scan'208";a="160121390" Received: from mx2.u-psud.fr ([129.175.212.65]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 12 Jan 2016 10:38:21 +0100 Received: from mx2.u-psud.fr (mx2 [127.0.0.1]) by localhost (MTA) with SMTP id 67A4B30312E for ; Tue, 12 Jan 2016 10:38:21 +0100 (CET) Received: from ext.lri.fr (ext.lri.fr [129.175.15.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.u-psud.fr (MTA) with ESMTPS id 023EF3030F7 for ; Tue, 12 Jan 2016 10:38:21 +0100 (CET) Received: from [129.175.15.4] (ext.lri.fr [129.175.15.4]) by ext.lri.fr (Postfix) with ESMTP id E3F504055C for ; Tue, 12 Jan 2016 10:38:20 +0100 (CET) Received: from [129.175.15.4] (ext.lri.fr [129.175.15.4]) by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd-pm8eQobD5 for ; Tue, 12 Jan 2016 10:38:20 +0100 (CET) Received: from [129.175.15.4] (ext.lri.fr [129.175.15.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ext.lri.fr (Postfix) with ESMTPSA id BF81C40434 for ; Tue, 12 Jan 2016 10:38:20 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id f206so310049716wmf.0 for ; Tue, 12 Jan 2016 01:38:20 -0800 (PST) X-Gm-Message-State: ALoCoQkBfHoOKJVcynwGduiq4zzr5lmRl0BHgp0uwsqqM2n+2UsCsePjhJBBuWhNZJyp8n0gDuYIiWECN+KgUSi3WrBM1+21nA== X-Received: by 10.28.210.143 with SMTP id j137mr18204372wmg.13.1452591499611; Tue, 12 Jan 2016 01:38:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.210.198 with HTTP; Tue, 12 Jan 2016 01:37:40 -0800 (PST) In-Reply-To: <965631B03C670145ABB9F693E51622530D0D763B@DENBGAT9EK5MSX.ww902.siemens.net> References: <965631B03C670145ABB9F693E51622530D0D763B@DENBGAT9EK5MSX.ww902.siemens.net> From: =?UTF-8?B?S2ltIE5ndXnhu4Vu?= Date: Tue, 12 Jan 2016 10:37:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Neuhaeusser, Martin" Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Validation-by: kim.nguyen@lri.fr Subject: Re: [Caml-list] The OCaml garbage collector, finalisers, and the right way of disposing native pointers in C bindings Hi, On Tue, Jan 12, 2016 at 10:12 AM, Neuhaeusser, Martin wrote: > Dear all, > > I assume this is a common problem in writing interfaces to C libraries. I= f 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 ocam= l_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 ma= cros, 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 no= thing with it and whose calls do not get optimized away by the compiler... = Evaluating such a function after the call to NativeLib.native_function woul= d prevent the GC from collecting ocaml_record. However, this feels like a v= ery 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 =E2=80=A6 but sill). Cheers, -- Kim