From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Riesen Subject: Re: First cut at git port to Cygwin Date: Fri, 7 Oct 2005 22:54:50 +0200 Message-ID: <20051007205450.GA14827@steel.home> References: <434299DB.7020805@zytor.com> <81b0412b0510050424h21fc06bav7677911f52b38426@mail.gmail.com> <81b0412b0510050846l2258775co117bada2d2b5a1ad@mail.gmail.com> <20051005155457.GA30303@trixie.casa.cgf.cx> <20051005191741.GA25493@steel.home> <20051005202947.GA6184@trixie.casa.cgf.cx> <81b0412b0510060205v4cd510c9wb4b06a3ed9242c8@mail.gmail.com> <81b0412b0510060307q431b64edt4196553bce28346c@mail.gmail.com> <81b0412b0510070544v3e7cf0b4n521db8ff7e4e335a@mail.gmail.com> Reply-To: Alex Riesen Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , Christopher Faylor , Junio C Hamano , "H. Peter Anvin" X-From: git-owner@vger.kernel.org Fri Oct 07 22:56:43 2005 Return-path: Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ENzFh-0005O2-OL for gcvg-git@gmane.org; Fri, 07 Oct 2005 22:55:38 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030554AbVJGUzT (ORCPT ); Fri, 7 Oct 2005 16:55:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030558AbVJGUzT (ORCPT ); Fri, 7 Oct 2005 16:55:19 -0400 Received: from devrace.com ([198.63.210.113]:62477 "EHLO devrace.com") by vger.kernel.org with ESMTP id S1030554AbVJGUzS (ORCPT ); Fri, 7 Oct 2005 16:55:18 -0400 Received: from tigra.home (p54A0E11D.dip.t-dialin.net [84.160.225.29]) (authenticated bits=0) by devrace.com (8.12.11/8.12.11) with ESMTP id j97L7JEP080430; Fri, 7 Oct 2005 16:07:20 -0500 (CDT) (envelope-from fork0@users.sourceforge.net) Received: from steel.home ([192.168.1.2]) by tigra.home with esmtp (Exim 3.36 #1 (Debian)) id 1ENzEy-0005W4-00; Fri, 07 Oct 2005 22:54:52 +0200 Received: from raa by steel.home with local (Exim 4.42 #1 (Debian)) id 1ENzEx-0000NW-E2; Fri, 07 Oct 2005 22:54:51 +0200 To: Git Mailing List Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=1.3 required=4.5 tests=AWL,BAYES_40, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on devrace.com Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Linus Torvalds, Fri, Oct 07, 2005 17:34:19 +0200: > > it suddenly get worse: now I'm stuck on git-pull. > > > > git-merge-index (called at some point by git-pull) maps the index > > in, and starts git-merge-one-file for each (or the given) entry in > > the index. git-merge-one-file calls git-update-index, which wants > > to update the index. Which doesn't work, because it's locked by > > that piece of s$%^. > > NOTE! git doesn't use mmap() because it _needs_ to use mmap(), but because > it was simple to do that way, and it's a total idiosyncracy of mine that I > often try to mmap the data. I often also tend to do my own allocators > instead of using malloc() (see my "sparse" project in case you're > interested in other idiosyncracies of mine - macros to do list traversal > etc). > > The fact is, "mmap()" isn't really any better than "read()": it has some > advantages wrt memory management for the kernel, which is probably one big > reason why I do it, but quite frankly, if you were to change every single > mmap() to be a "map_file()" instead, and made it optional whether it used > mmap() or "malloc + read()", I personally don't think it would be > horrible. > > And it might make things much simpler for portability. The "use mmap" > approach is very much a unixism, particularly the way unix people do it > (mmap followed by close, making the file descriptor "go away"). Sure, > other OS's have mmap too, but I think on them it tends to be less commonly > used. "Sounds like a thinly veiled threat or a very effective prodding" 8) --- Make read_cache copy the index into memory, to improve portability on other OS's which have mmap too, tend to use it less commonly. Signed-off-by: Alex Riesen diff --git a/read-cache.c b/read-cache.c --- a/read-cache.c +++ b/read-cache.c @@ -497,9 +497,11 @@ int read_cache(void) offset = sizeof(*hdr); for (i = 0; i < active_nr; i++) { struct cache_entry *ce = map + offset; - offset = offset + ce_size(ce); - active_cache[i] = ce; + size_t size = ce_size(ce); + offset = offset + size; + active_cache[i] = malloc(ce, size); } + munmap(map, size); return active_nr; unmap: