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 1F2B97FACD for ; Thu, 18 Sep 2014 10:24:46 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.219.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.219.41 as permitted sender) identity=mailfrom; client-ip=209.85.219.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oa0-f41.google.com) identity=helo; client-ip=209.85.219.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-oa0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggCAPeVGlTRVdspm2dsb2JhbABGEgiCR4EZVwSCfMRQgW2HDT4BgQIIFgERAQEBAQEGCwsJFCqEBAEBAwESER0BGx0BAwELBgULNwICIgERAQUBHAYTCBMHiAcBAwkIDTadKmuLMIFygxCJKQoZJw1mhkEBEQEFDo58F1IEB4J4gVMFhh+JGYMZgzSHB4FgjSmETRgphRE7LwEEgkUBAQE X-IPAS-Result: AggCAPeVGlTRVdspm2dsb2JhbABGEgiCR4EZVwSCfMRQgW2HDT4BgQIIFgERAQEBAQEGCwsJFCqEBAEBAwESER0BGx0BAwELBgULNwICIgERAQUBHAYTCBMHiAcBAwkIDTadKmuLMIFygxCJKQoZJw1mhkEBEQEFDo58F1IEB4J4gVMFhh+JGYMZgzSHB4FgjSmETRgphRE7LwEEgkUBAQE X-IronPort-AV: E=Sophos;i="5.04,545,1406584800"; d="scan'208";a="79876842" Received: from mail-oa0-f41.google.com ([209.85.219.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Sep 2014 10:24:44 +0200 Received: by mail-oa0-f41.google.com with SMTP id o6so404537oag.28 for ; Thu, 18 Sep 2014 01:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oMI9rEdttFeb3UP4/80GO4tSTXt8vzHYCVqgYfFhzjw=; b=0mDfrHCI5399qVm9M5T4vyigwofGtbDd3/sPi9mh2+jNnUB8QroD2ePP1LIc7TVVIv Am6/cCaj2NS/efro23AiWKMug9UR9yzeOmTw1DaYZoqxf+dqbfXVI/myic8DGky7FkVe 1ctC/TmwNf5CF3Ipn1naaeuaC+q+PgU9RoEk4h+5zQdOnT0MkT4EOCkoZCUo9d4l9e27 HOIXuML47wHe5Tlj0RGog/1mPddgg/FhjsGXLKxXVm5m/34tgr3EROKIlH0lAzp0vIBq 4s7ZnaKqOztB51Ou7p25fX0Gy4gQrAmZ/qX6bo8/dkTrfcmPTaCyV/UObp6cBEk1H23f TYIQ== X-Received: by 10.182.38.138 with SMTP id g10mr2593358obk.21.1411028683418; Thu, 18 Sep 2014 01:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.141.165 with HTTP; Thu, 18 Sep 2014 01:24:03 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Thu, 18 Sep 2014 10:24:03 +0200 Message-ID: To: "Bauer, Christoph" Cc: caml-list Content-Type: multipart/alternative; boundary=001a11c2ec5a7172ab050352b749 Subject: Re: [Caml-list] memory mapped files with bigarray on windows --001a11c2ec5a7172ab050352b749 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There were experiments adding an explicit "unmap this bigarray" operation to the runtime: see Apr 2012 commit https://github.com/ocaml/ocaml/commit/2330a3b30fe5b910f4776bf9c41f35ce2b980= fb1 However, this change was reverted shortly thereafter because of performance concerns: it changes the invariant that the size of a live bigarray never changes, which makes it easier to optimize away bound checks. Could you please create a bug report ( http://caml.inria.fr/mantis/ ) to keep track of your particular issue with lack of explicit bigarray closure? I haven't found traces of it in the bugtracker ( the rather old bug http://caml.inria.fr/mantis/view.php?id=3D3571 is about the need to call msync() in a NFS setting, but doesn't touch explicit closure ), so it may not have been previously known. On Thu, Sep 18, 2014 at 10:04 AM, Bauer, Christoph < bauerchristoph@siemens.com> wrote: > Dear All, > > > > my program maps several blocks of a file into memory with > Bigarray.Array1.map_file for writing. > > Finally the file handle is closed with Unix.close. > > > > On local files system everything works as expected. But if the file is on > a network drive, > > the resulting file is after the close still locked [1] and it contains > just zeros. > > > > My workaround is, to call Gc.full_major() before the close. Then all > remaining bigarrays are > > finalized (the finalizer calls caml_ba_unmap_file(), see > bigarray_stubs.c). > > > > Calling Gc.full_major () is somewhat dissatisfying. But I=E2=80=99m not s= ure how > it could be solved more cleanly. > > I would expect that Unix.close should unmap all remaining views of the > file. But Unix.close knows nothing > > about the bigarray mapping. > > > > Maybe a special Bigarray.unmap is the solution. > > > > Does anyone has a better idea? > > > > Thanks, > > Christoph Bauer > > > > [1] You can=E2=80=99t delete it in the windows explorer. > > > > > > ----------------- > Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, > 50823 K=C3=B6ln; > Kommanditgesellschaft: Sitz der Gesellschaft: K=C3=B6ln; Registergericht: > Amtsgericht K=C3=B6ln, HRA 28227; > Gesch=C3=A4ftsf=C3=BChrung und pers=C3=B6nlich haftender Gesellschafter: = Siemens Industry > Software Management GmbH; > Gesch=C3=A4ftsf=C3=BChrer: Urban August, Daniel Trebes; Sitz der Gesellsc= haft: K=C3=B6ln; > Registergericht: Amtsgericht K=C3=B6ln, HRB 70858 > --001a11c2ec5a7172ab050352b749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There were experiments adding an explicit "= unmap this bigarray" operation to the runtime: see Apr 2012 commit
= =C2=A0 https://github.com/ocaml/ocaml/commit/2330a3b30fe5b9= 10f4776bf9c41f35ce2b980fb1
However, this change was reverted s= hortly thereafter because of performance concerns: it changes the invariant= that the size of a live bigarray never changes, which makes it easier to o= ptimize away bound checks.

Could you please create a bug repor= t ( http://caml.inria.fr/mantis/ ) to keep track of your particular issue with lack of explicit bigarray = closure? I haven't found traces of it in the bugtracker ( the rather ol= d bug http://cam= l.inria.fr/mantis/view.php?id=3D3571 is about the need to call msync() = in a NFS setting, but doesn't touch explicit closure ), so it may not h= ave been previously known.

On Thu, Sep 18, 2014 at 10:04 AM, Bauer, Christoph <bauerchristoph@siemens.com> wrote:

Dear All,

=C2=A0

my program maps =C2=A0several b= locks of a file into memory with Bigarray.Array1.map_file for writing.

Finally the file handle is clos= ed with Unix.close.

=C2=A0

On local files system everythin= g works as expected. But if the file is on a network drive,

the resulting file is after the= close still =C2=A0locked [1] and it contains just zeros.

=C2=A0

My workaround is, to call =C2= =A0Gc.full_major() before the close. Then all remaining bigarrays are

finalized (the finalizer calls = caml_ba_unmap_file(), see bigarray_stubs.c).

=C2=A0

Calling Gc.full_major () is som= ewhat dissatisfying. But I=E2=80=99m not sure how it could be solved more c= leanly.

I would expect that Unix.close = should unmap all remaining views of the file. But Unix.close knows nothing<= /span>

about the bigarray mapping.

=C2=A0

Maybe a special Bigarray.unmap = is the solution.

=C2=A0

Does anyone has a better idea?<= /span>

=C2=A0

Thanks,

Christoph Bauer

=C2=A0

[1] You can=E2=80=99t delete it= in the windows explorer.

=C2=A0

=C2=A0

-----------------
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10= , 50823 K=C3=B6ln;
Kommanditgesellschaft: Sitz der Gesellschaft: K=C3=B6ln; Registergericht: A= mtsgericht K=C3=B6ln, HRA 28227;
Gesch=C3=A4ftsf=C3=BChrung und pers=C3=B6nlich haftender Gesellschafter: Si= emens Industry Software Management GmbH;
Gesch=C3=A4ftsf=C3=BChrer: Urban August, Daniel Trebes; Sitz der Gesellscha= ft: K=C3=B6ln; Registergericht: Amtsgericht K=C3=B6ln, HRB 70858


--001a11c2ec5a7172ab050352b749--