Xref: utzoo comp.editors:1247 gnu.emacs:2102 comp.unix.wizards:20045
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!neon!neon!gumby
From: gumby@Gang-of-Four.Stanford.EDU (David Vinayak Wallace)
Newsgroups: comp.editors,gnu.emacs,comp.unix.wizards
Subject: Re: Mach and faulting in the file (Re: GNU Emacs, memory usage, releasing)
Message-ID: <GUMBY.90Jan7184250@Gang-of-Four.Stanford.EDU>
Date: 8 Jan 90 02:42:50 GMT
References: <1558@aber-cs.UUCP> <129799@sun.Eng.Sun.COM> <50359@bbn.COM>
	<IN_S4Eggpc2@ficc.uu.net>
	<GUMBY.90Jan6045022@Gang-of-Four.Stanford.EDU>
	<2J+IH7ggpc2@ficc.uu.net>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Computer Science Department, Stanford University
Lines: 22
In-Reply-To: peter@ficc.uu.net's message of 7 Jan 90 20:05:37 GMT


   Date: 7 Jan 90 20:05:37 GMT
   From: peter@ficc.uu.net (Peter da Silva)

   What I mean here is that you can allocate your block poimters, then call
   map_fd to map the file into memory. Now you point your block pointers into
   the file, but don't actually touch the memory.

The problem is that unless you copy the file on disk you can't back
out of your edits at the last moment (:q! for vi people).  If you're
going to copy the file you might as well copy it into vmem.

   > 3> Allow the program to change the page mapping 

   THAT is the thing to do to "fix" buffer gap. If you can do that you can also
   call map_fd to get the initial buffer. The problem with this is that now
   the program (or its custom external pager) is having to do much of the work
   of a block-splitting algorithm.

malloc already does most of the required work.  You could add a system
call or system macro to tell you how to xlate a page index from a
pointer and bingo.