From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Fri, 28 Oct 2016 08:11:17 -0400 Message-ID: References: <83zilvm2ud.fsf@gnu.org> <83r377m0i8.fsf@gnu.org> <83eg36n6v5.fsf@gnu.org> <83shrl523p.fsf@gnu.org> <83eg354ux3.fsf@gnu.org> <4f0c2868-d408-a5c4-d5a8-90dae750eb33@dancol.org> <878tt9ggdk.fsf@ritchie.wxcvbn.org> <83k2cssypt.fsf@gnu.org> <6350b2df-fde9-e716-d279-9f29438f8ee5@dancol.org> <83d1ikswsf.fsf@gnu.org> <7ab47b94-c662-1351-0dd3-ed5269842438@dancol.org> <83bmy4stax.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477664281 20469 195.159.176.226 (28 Oct 2016 14:18:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 14:18:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Daniel Colascione , emacs-devel@gnu.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 28 16:17:57 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c07yc-0003SM-C4 for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 16:17:46 +0200 Original-Received: from localhost ([::1]:49378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c07ye-0005TP-RX for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 10:17:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c07ub-0003Q5-HV for emacs-devel@gnu.org; Fri, 28 Oct 2016 10:13:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c07uV-0001nD-W6 for emacs-devel@gnu.org; Fri, 28 Oct 2016 10:13:37 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:3210) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c07uS-0001lx-6q; Fri, 28 Oct 2016 10:13:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHAgALW9BX/9ly3mhdGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kiFUIvFUBAQgCJYp9ihwBBJlZmQ2GC5BLHjaEbCCGCgEBAQ X-IPAS-Result: A0BHAgALW9BX/9ly3mhdGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kiFUIvFUBAQgCJYp9ihwBBJlZmQ2GC5BLHjaEbCCGCgEBAQ X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="277437613" Original-Received: from 104-222-114-217.cpe.teksavvy.com (HELO pastel.home) ([104.222.114.217]) by smtp.teksavvy.com with ESMTP; 28 Oct 2016 10:13:24 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 37D3C65431; Fri, 28 Oct 2016 08:11:17 -0400 (EDT) In-Reply-To: <83bmy4stax.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 28 Oct 2016 12:43:02 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208945 Archived-At: > If reserving a range of addresses doesn't necessarily mean they will > be later available for committing, then what is the purpose of > reserving them in the first place? What good does it do? My guess is that you can later use that address space to mmap files in there. Equivalently, you could increase the swap space between the time you PROT_NONE and the time you switch to PROT_RW. PROT_NONE is useful in a situation such as ours: you want to mmap a hundred buffers, and make sure you can grow any of them without knowing beforehand which one will grow. But most likely, whether it's useful or not to be able to reserve 80TB of address space even if you'd never be able to PROT_RW later was not really relevant to the design of the API. Stefan