X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=k6b2FRIOzfTHaisu
	ftq9bFPkcS4kZceuk/qsxa5sScAJhx4SDhWhlWekJCmByCyVidOIrGf4Y+VJmvbX
	lXRi0kLCr+6VbQwJua1n6MMsVeahNVpFmc0dHOxYtggPmki+70+WcZKtJKswZ/RE
	aN0jFuRswTqhVLjHw6bUHCOGlDY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=kue8Q4MBJZpxQxUq3dN4P2
	13odg=; b=jWXU//6yTD0H1ZxGURLMGQSG066dM5H8oPNXhmiFXyEgZ5YSsb/Rhf
	dRw3/4alAAeoaAuD4F43/bSAgE4M50/pTezxIOdUQMK0snj7BEWI2xP8wS8cKGS1
	X/t0s3iFgsmh4LUfm7pdW11j4lmBHgq5HEO+wT8E6uKv9rGVkP3r0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=
X-HELO: limerock02.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Subject: Re: Atomic mmap replacement
To: cygwin AT cygwin DOT com
References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0 AT cornell DOT edu> <20180219090042 DOT GC3417 AT calimero DOT vinschen DOT de> <bf821c51-5cea-a3b9-3b24-812cdb8a7b9c AT cornell DOT edu> <20180219171914 DOT GA3619 AT calimero DOT vinschen DOT de>
From: Ken Brown <kbrown AT cornell DOT edu>
Message-ID: <e5417923-d1cf-1f2e-ef9d-fd50eef60581@cornell.edu>
Date: Mon, 19 Feb 2018 17:33:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180219171914.GA3619@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Cornell-Gauge: Gauge=XXXXX
X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none;
X-IsSubscribed: yes

On 2/19/2018 12:19 PM, Corinna Vinschen wrote:
> On Feb 19 08:22, Ken Brown wrote:
>> On 2/19/2018 4:00 AM, Corinna Vinschen wrote:
>>> On Feb 17 22:37, Ken Brown wrote:
>>>> Some code in emacs wants to reserve a chunk of address space with a big
>>>> PROT_NONE anonymous mapping, and then carve it up into separate mappings
>>>> associated to segments of a file.  This fails on Cygwin.  Here's a test case
>>>> that illustrates the problem:
>>>> [...]
>>> Several limitations in the Windows kernel disallow this:
>>>
>>> - It doesn't allow to unmap parts of a map, only the entire map as a
>>>     whole.
>>>     Cygwin has a workaround: If you unmap parts of a map it just keeps
>>>     track of this and sets the protection of the affected pages to
>>>     PAGE_NOACCESS.  In case of anonymous mappings, it even recycles them
>>>     potentially for other mappings.
>>>
>>> - It also disallows to re-map any allocated or mapped mamory for another
>>>     purpose.
>>>
>>> So this part of the POSIX specs for mmap:
>>>
>>>     "The mapping established by mmap() shall replace any previous mappings
>>>      for those whole pages containing any part of the address space of the
>>>      process starting at pa and continuing for len bytes"
>>>
>>> can't be implemented with Windows means.
>>>
>>> The only workaround possible would be to handle this *exact* scenario as
>>> a special case in Cygwin's mmap:  If the new mapping falls in the middle
>>> of an existing mapping and if the original mapping was an anonymous
>>> mapping with PROT_NONE page protection, then
> 
> On second thought, we *could* do this, if the pages have been mmapped
> before(*).  Unfortunately this would require a *major* revamp of the
> page handling in mmap.  We would have to keep the mapping of every
> single 64K page separate.
> 
> I.e., requesting a file mapping of 256K at offset 0 on the POSIX level
> would have to be handled as four Windows file mappings under the hood:
> 
> 1. a 64K file mapping at offset 0
> 2. a 64K file mapping at offset 65536
> 3. a 64K file mapping at offset 131072
> 4. a 64K file mapping at offset 196608
> 
> A request to mmap another 64K page to the third mapping in this example
> could then be done by unmapping the third mapping and replace it with
> the requested mapping.
> 
> I'm not sure this is feasible.  It would complicate and slow down the
> code especially for big mappings; one call to NtCreateSection and one to
> NtMapViewOfSection per 64K page, plus the overhead of making sure that
> all mappings are in the right, sequential order in memory.  Plus the
> overhead of having to remap a lot more mappings in forked children.  The
> "Cygwin is slow" meme would get another interesting facet :}

That doesn't sound great.

In the meantime, the problem was solved on the emacs side by doing what 
you suggested in your previous email:

 > - unmap the old mapping
 > - remap the unaffected parts as separate anonymous mapping
 > - map the affected parts for the requested file mapping

But in the emacs application it's simpler, because there are no 
unaffected parts, so step 2 can be skipped.

Thanks.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple