Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Sun bogosities, including MMU thrashing Message-ID: Date: 29 Jan 91 14:39:04 GMT References: <1991Jan27.003821.24814@unx2.ucc.okstate.edu> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 42 Nntp-Posting-Host: odin In-reply-to: minich@unx2.ucc.okstate.edu's message of 27 Jan 91 00:38:21 GMT On 27 Jan 91 00:38:21 GMT, minich@unx2.ucc.okstate.edu (Robert Minich) said: suitti> [ ... describing a log based editor instead of a copy based one suitti> like, in different ways, vi or emacs ... ] Grandi> Precisely what I think is the best organization! Especially for Grandi> virtual memory. Another nice organization was used by the TSS/370 Grandi> editor, which used VSAM (then called another way) for (memory Grandi> mapped) files. minich> With a log based editor, what happens if someone changes the file while minich> you're editing it? Are the files locked while in use? Well, the problem exists in any editor organization; if two users edit the same file, the end result will be either one of the two modified copies or any in between mix, with no guarantee (if two copy based editors copy back at the same time, funny things will be written). The only way to guarantee consistency is to use locking, under any editor structure. It is arguable whether locking should be in the editor itself. One can use RCS or SCCS for example to ensure atomic updates, or even branches. Or one can use something like the technology used in Locus. Going back to VM, it is interesting to note that copy-on-write may help here. Also note the particular implementation of the MasPar and its way of duplicating pages and then merging them back. There are many ways to solve the concurrent modification problem. The semantics of concurrent modifications are an architectural issue orthogonal to how the editor is implemented. The two interact, but performance wise. Some editor organizations are better in some cases, some in others. Copy based editors are attractive under Unix mainly because of the heavy preference given to sequential reads and writes theu the filesystem. Now that Unix implementations are moving towards Multics/TSS370 like memory mapped files with a very poor performance profile for sequential access maybe things will change. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk