X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Mon, 18 Jun 2012 16:51:19 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Windows 8 Release Preview. fork problems with rsync Message-ID: <20120618145119.GB26243@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20120606123434 DOT GA27662 AT calimero DOT vinschen DOT de> <20120606161217 DOT GB30795 AT calimero DOT vinschen DOT de> <4FD0BC4C DOT 1070603 AT cs DOT utoronto DOT ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FD0BC4C.1070603@cs.utoronto.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Jun 7 10:35, Ryan Johnson wrote: > On 06/06/2012 12:12 PM, Corinna Vinschen wrote: > >On Jun 6 16:41, Bertrand Latinville wrote: > >>I'm using > >> > >> rsync --chmod=ug=rwX -arvz --prune-empty-dirs --include="*/" > >>--include-from=include-file.txt --exclude="*" ${source_dir}/ > >>${dest_dir} > >Thanks. I can confirm the effect. For no apparent reason, the OS > >reserves a 1 Megs shared memory region, top-down allocated, of which it > >uses about 20K. It's not the PEB or one of the TEBs, though. Nor is > >it a thread stack. I checked, and it turns out that it's allocated > >in every process, on 32 and 64 bit systems. That's kind of worrying > >since that's bound to collide with mmaped regions and pthread stacks a > >lot. I don't know what to do at this point. > Given that the OS always gets there first, why not just adjust > Cygwin's definition of "top" for win8? Or does heap randomization > move that mystery chunk around? Yes, the chunk is moved around. Thousands of tests show a lowest memory slot, but the problem is that top-down allocation is not a manual functionality done by Cygwin. It's just a flag in calls to VirtualAlloc or MapViewOfFileEx. Therefore, if we have to define our own highest memory slot, it requires Cygwin to do some trickery on its own, which was just not necessary so far. I'm going to ask Microsoft about this issue first. Maybe it's something only in the release preview which will go away in the gold release. If so, I won't start to workaround it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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