220 39522 article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: D1031R1 draft 1 LLFIO with proposed C++ object model and lifetime changes for mapped memory support Date: Fri, 3 Aug 2018 09:34:41 -0700 (PDT) Lines: 147 Approved: news@gmane.org Message-ID: References: <096f1d1c-3e2e-4df8-91ee-6f1cf4d31aad@isocpp.org> <58f8fc09-102e-4378-97f9-308b96547a1a@isocpp.org> <91b6e70f-1657-43e1-803c-a119c81ca1b9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_710_1719717014.1533314081337" X-Trace: blaine.gmane.org 1533313956 18442 195.159.176.226 (3 Aug 2018 16:32:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2018 16:32:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBIUISLNQKGQE73URLMA@isocpp.org Fri Aug 03 18:32:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fld0C-0004hL-Hr for gclcip-std-proposals@m.gmane.org; Fri, 03 Aug 2018 18:32:32 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id y8-v6sf5432394ybm.15 for ; Fri, 03 Aug 2018 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=/zmcW4ssPXi5TVTB9byR+Cty7Ez2OxxvwqqD7fnXeyY=; b=okZC2WzMovTJRKN2GH29xzj6gJOn5LK5sDaNnfHpCYxMRC/NJbcRTOOB5f2TyeVbYm 2rxgyd8MllXOlR1adhpoiEWmSzntbzoVxfZZNJFHL1qNzvNNYJR+5J+MZhSpUNja3kKS HT4e3Bf903iKEAkWn2i3JwPRz77lCtFM05GvunOPDe58DUPwnpaVdmuWU5Wf+AAr8phQ aFgpgXAYd8q90lO9c1B16+IGIOvBYI0u2igABUGZrKAuICykor5bSYoEUGc9UlRE0BtP LuFvA24HoN+h/k3sFG3i8UkTLLk0r0qISNzRF8MV9XBxz9JuaGGC/Wbvp41IF2Ee/h54 DqwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=/zmcW4ssPXi5TVTB9byR+Cty7Ez2OxxvwqqD7fnXeyY=; b=D7zVoD74Ux7fxwcBImgzdGhv5ZqQROdvJ4w9N/LZaqUx9bJhdN191szEhv5qBL+yE3 YuJ4dgFb+Yj/Fw8+tJjgm+FAxSQ7qy70/cPtZmndDqefH8EBqauV142/JIE9utonNOP9 y3WJR7s2zWSzyf4etqs2O0I0lkQqwOlm6E+3pHnFMO464zyNgzH6pp7dMNeWnDaS+ZTL cOWy9s3s5AZjmA1cBPUeX8SJ179ZT7LWJdLOhD8Is1J5Hsn4bdfq5eSkJOWT94u7CORF VyCVPedWKviHD9il6oerkOsoyvQatEDm83Uochunxc2kn5lnV1KNDihYlNe7w0rMzbyX pxLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=/zmcW4ssPXi5TVTB9byR+Cty7Ez2OxxvwqqD7fnXeyY=; b=glYu9fKirA52oJFBELrlUoY6PBg6mTYMV0w06B1LChx2xFDB9m4lYoAPMMsoMlXqOs z6AVcSmnRl30OQNY8m3YudrogLSuGdQIN1UWoXrRz5gnFYuIy0GMGw5Dj6sWjrWOO4Cc 0c0//MQfo+gO6A8ywHETn6yCOAETeyg4fjbb7l6YO78aOJ231XYD9tUQf+rGJO2DgW4/ zcYVZZOaFnlvaRRAa7oAJlV7mePwo34ISFsAPLsloAhsa1LW16gnQxqwL7zqPoJsx+Gj OFpJlmZh2pRaCu1/E0p5EnioOO6T2RMT6vfIImYOMsXtZko8ZHd6Gd6iQOUXwqG0k9iQ xaGA== X-Gm-Message-State: AOUpUlGxd++u/8yWp7GzoCufD3BPLODDLPVeyt02lZWlseEXGovOJjf+ 62EvzFiYBEfGJj9tCtVvrX8nLQ== X-Google-Smtp-Source: AAOMgpezE6QsqirChV6eZhtOgWMNB0UhbDZqQW4BV7ze9QZdJKittiEN2tK68fi8KSAOCwD4V2BbEg== X-Received: by 2002:a81:61c4:: with SMTP id v187-v6mr2509926ywb.119.1533314083085; Fri, 03 Aug 2018 09:34:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:5181:: with SMTP id f123-v6ls1013768ywb.20.gmail; Fri, 03 Aug 2018 09:34:42 -0700 (PDT) X-Received: by 2002:a81:3807:: with SMTP id f7-v6mr171066ywa.4.1533314081826; Fri, 03 Aug 2018 09:34:41 -0700 (PDT) In-Reply-To: <91b6e70f-1657-43e1-803c-a119c81ca1b9@isocpp.org> X-Original-Sender: nialldouglas14@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:39522 Archived-At: ------=_Part_710_1719717014.1533314081337 Content-Type: multipart/alternative; boundary="----=_Part_711_473520778.1533314081337" ------=_Part_711_473520778.1533314081337 Content-Type: text/plain; charset="UTF-8" > > > "New allocations are guaranteed to be all bits zero on creation." > This is almost always going to be the case in hosted environments for > security reasons. On freestanding implementations, the zero'ing isn't a > sunk cost like it is on hosted implementations. I think that you should > say that the contents are unspecified on creation. > I haven't written the documentation for section_handle yet, but you'll find that the unbacked constructor will say exactly this. The backed constructor says nothing, because it's the backing file_handle which does the zeroing when you extend the file. And zeroing here isn't writing zeros to memory, it's the kernel zero page, on first write the page fault then allocates storage on the drive which is only then zeroed on non-TRIM devices. Historically some embedded systems with filing systems did not zero file extensions, but I am unaware of any major embedded systems with filing systems in the past decade which don't. For example Windows CE didn't originally, but then started to because it was a giant security hole. > > 3.1.4 > I'm not super interested in mapped polymorphic objects. I am interested > in having objects reachable from multiple mappings simultaneously. > Inter-process communication with shared memory is a real thing, and I think > mapped storage in combination with regular C++11 atomics makes it work. > Technically speaking, if you read the standard wording, it currently provides no guarantees that atomics work outside of the threads running in the current process. I am all for your help in changing that, but I would assume that your plate is fairly full right now. > > I expect resistance from the implementers when it comes to modifying the > vptr. Optimizers can currently assume it won't change, except when going > through launder barriers. > Maybe Nicol is right. If we end and start lifetime, that enables vptr restamping within the current object lifetime framework. But you are right, the compiler vendors are between cold and freezing on this proposal. > 3.2 > I generally like it. You might want to see if there is any further > inspiration to draw from gcc assembly clobber lists. > > It's probably not widely known yet, but there is a new effort to deprecate volatile in C++ which may or may not become a big push soon. So we may actually see a std::clobber(std::byte *, std::size_t) which tells the compiler to reload any bytes within that range. Niall -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d6c1a29e-eab4-460e-a4e7-22faa32a50e6%40isocpp.org. ------=_Part_711_473520778.1533314081337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

"New allocations are guaranteed to be all= bits zero on creation."
This is almost always going to be t= he case in hosted environments for security reasons.=C2=A0 On freestanding = implementations, the zero'ing isn't a sunk cost like it is on hoste= d implementations.=C2=A0 I think that you should say that the contents are = unspecified on creation.

= I haven't written the documentation for section_handle yet, but you'= ;ll find that the unbacked constructor will say exactly this. The backed co= nstructor says nothing, because it's the backing file_handle which does= the zeroing when you extend the file. And zeroing here isn't writing z= eros to memory, it's the kernel zero page, on first write the page faul= t then allocates storage on the drive which is only then zeroed on non-TRIM= devices.

Historically some embedded systems with = filing systems did not zero file extensions, but I am unaware of any major = embedded systems with filing systems in the past decade which don't. Fo= r example Windows CE didn't originally, but then started to because it = was a giant security hole.
=C2=A0

3.1.4
I'm not super interested in mapped polymorphic objects.=C2=A0 I am in= terested in having objects reachable from multiple mappings simultaneously.= =C2=A0 Inter-process communication with shared memory is a real thing, and = I think mapped storage in combination with regular C++11 atomics makes it w= ork.

Technically speaking= , if you read the standard wording, it currently provides no guarantees tha= t atomics work outside of the threads running in the current process.
=

I am all for your help in changing that, but I would as= sume that your plate is fairly full right now.
=C2=A0

I expect resistance from the implementers when it comes to modifying = the vptr.=C2=A0 Optimizers can currently assume it won't change, except= when going through launder barriers.
Maybe Nicol is right. If we end and start lifetime, that enabl= es vptr restamping within the current object lifetime framework. But you ar= e right, the compiler vendors are between cold and freezing on this proposa= l.
=C2=A0
3.2
I generally like it.=C2=A0 You might wan= t to see if there is any further inspiration to draw from gcc assembly clob= ber lists.

It's probably no= t widely known yet, but there is a new effort to deprecate volatile in C++ = which may or may not become a big push soon. So we may actually see a std::= clobber(std::byte *, std::size_t) which tells the compiler to reload any by= tes within that range.

Niall

<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/d6c1a29e-eab4-460e-a4e7-22faa32a50e6= %40isocpp.org.
------=_Part_711_473520778.1533314081337-- ------=_Part_710_1719717014.1533314081337-- .