From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 656717F7C3 for ; Tue, 4 Feb 2014 16:32:23 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtACAD4H8VLU4w8Em2dsb2JhbABZg0S5HIVSgQsWDgEBAQEBBgsLCRQogiUBAQU6GzQLGAkaCw8FDRs0h3ABAxXEGh8rDRWJHheMYIIcFoMOgRQElj+Ba4YyEoQMgg+HMoE/ X-IPAS-Result: AtACAD4H8VLU4w8Em2dsb2JhbABZg0S5HIVSgQsWDgEBAQEBBgsLCRQogiUBAQU6GzQLGAkaCw8FDRs0h3ABAxXEGh8rDRWJHheMYIIcFoMOgRQElj+Ba4YyEoQMgg+HMoE/ X-IronPort-AV: E=Sophos;i="4.95,780,1384297200"; d="scan'208";a="56832397" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 04 Feb 2014 16:32:23 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0LuLxD-1VCjiL0kHH-011iVw for ; Tue, 04 Feb 2014 16:32:22 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1WAhz3-0005G3-JQ for caml-list@inria.fr; Tue, 04 Feb 2014 16:32:21 +0100 Date: Tue, 4 Feb 2014 16:32:21 +0100 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140204153221.GA20077@frosties> References: <20140201164203.GG1783@frosties> <20140202013846.GA11002@frosties> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:5F1KC1WZXQT6Zl8h25p9ZhFrhKlDNwloSX7g+Qf6CoEfhPhVt8g J49pyK6TC1bklJ5yhDdgKwsLJIQz18eQxW8GZzY0aW37SlCgiriUYUz/BPGI3xsCxM9AAbX I3v7OxCl2AWXRF0VInCEgX2NDMPUqvWC2BqZ816dGyiQBC7JW5Fj3r4vzUFO4hP5ONbosOo 0Vh3/jFYfW3b53quVJtjQ== Subject: Re: [Caml-list] Why is struct caml_ba_proxy allocated outside the GC heap and why doesn't it have a finalizer? On Sat, Feb 01, 2014 at 09:06:54PM -0500, Markus Mottl wrote: > On Sat, Feb 1, 2014 at 8:38 PM, Goswin von Brederlow wrote: > > The GC knows which pointers point inside the GC heap and which point > > outside. So there is no problem there. The pointer must just not exist > > after the destination has been freed or it might accidentaly point to > > inside the next GC heap. Can't happen in this use case. > > Exactly. Though the GC checks whether a pointer actually points into > the OCaml heap before following it, it does require some care to > guarantee that the pointer, if still reachable by the GC, is > invalidated (e.g. set to NULL) before associated memory is freed. > This may indeed not be that hard to achieve for the bigarray module. > I still prefer 2), which would also be easier to add to the current > implementation without breaking existing code. > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl@gmail.com Time to try out that new ocaml program to use git-hub for patches to the compiler. I will go with option 2 because it will not change anything in the compiler and the optimizations for bigarrays itself. It will only affect the C code fo allocation and dinalization. So should be far easier. I think I will add a new flag to the Bigarray structure that says when a "free" function was added to the proxy object. That way even if some software creates the proxy object themself (and won't have the free_fn pointer) this will work. MfG Goswin