From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <markus.mottl@gmail.com>
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 8E7B17F7B4
	for <caml-list@sympa.inria.fr>; Sun,  2 Feb 2014 03:06: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.181;
  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.181 as permitted
  sender) identity=mailfrom; client-ip=209.85.216.181;
  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-f181.google.com) identity=helo;
  client-ip=209.85.216.181;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="markus.mottl@gmail.com";
  x-sender="postmaster@mail-qc0-f181.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksCAB+n7VLRVdi1lGdsb2JhbABYg0RXvV+BAAgWDgEBAQEHCwsJEiqCJQEBBUABFAcdAQMMBgULDSMLIQEBEQEFARwGE4dwAQMRnzSMXIMJkyUKGScNFU+ITxEBBQyMZ4IWB4Q4BIlJjHWBbIpPgg+DVhgpgxuBXB4
X-IPAS-Result: AksCAB+n7VLRVdi1lGdsb2JhbABYg0RXvV+BAAgWDgEBAQEHCwsJEiqCJQEBBUABFAcdAQMMBgULDSMLIQEBEQEFARwGE4dwAQMRnzSMXIMJkyUKGScNFU+ITxEBBQyMZ4IWB4Q4BIlJjHWBbIpPgg+DVhgpgxuBXB4
X-IronPort-AV: E=Sophos;i="4.95,760,1384297200"; 
   d="scan'208";a="56456473"
Received: from mail-qc0-f181.google.com ([209.85.216.181])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Feb 2014 03:06:56 +0100
Received: by mail-qc0-f181.google.com with SMTP id e9so9341942qcy.12
        for <caml-list@inria.fr>; Sat, 01 Feb 2014 18:06: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=rogtKCjAsZDHO8ZuFhgvdxPUcQq5izrBJSzLO7F07SQ=;
        b=RpMUyPQcxDAUcmwlajidp1v4MfVWjSlWN/4G+rLUxOgMRw/FuLcnQfIWCyXkssY1Dh
         RPHpFNx5IQw7p0omk0bLrE2GahX/6iEOBvZ0uZG4k1DdysiDXD3gkblypEDQNj76gBiy
         5SJzGg/tEYGtjhdNth8FcxGNz2Bdqj9VQbrW5YWVPPJ4RWI38kx648AXrD+m6U3ctKdR
         tSdZiWIh6/rosWAUZ3WzLuJ7xYt0332ZMGGILMLuvd3RZHA3+NgfoWzl99fIuJAJY3fq
         2JIigI/MuE6lR7OtitxyL13v5bz+rnpz2IjkQI3/4pAmHY2xY+QesB9Fx7namcc7UJLz
         B2pQ==
MIME-Version: 1.0
X-Received: by 10.140.39.212 with SMTP id v78mr41798930qgv.77.1391306815031;
 Sat, 01 Feb 2014 18:06:55 -0800 (PST)
Received: by 10.140.90.70 with HTTP; Sat, 1 Feb 2014 18:06:54 -0800 (PST)
In-Reply-To: <20140202013846.GA11002@frosties>
References: <20140201164203.GG1783@frosties>
	<CAP_800r7KACq_gAfybMe4BZHHZ3Ukm=mg7dgPX31HQxLuEEQVg@mail.gmail.com>
	<20140202013846.GA11002@frosties>
Date: Sat, 1 Feb 2014 21:06:54 -0500
Message-ID: <CAP_800qpOzaTYSvz806tfsXxxCx0fs0dNAzoe51NykpoChd+Eg@mail.gmail.com>
From: Markus Mottl <markus.mottl@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: caml-list@inria.fr
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?

On Sat, Feb 1, 2014 at 8:38 PM, Goswin von Brederlow <goswin-v-b@web.de> 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