Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!necntc!custom!boykin
From: boykin@custom.UUCP (Joseph Boykin)
Newsgroups: comp.unix.questions
Subject: Re: vi glitch?
Message-ID: <757@custom.UUCP>
Date: Fri, 19-Jun-87 01:34:34 EDT
Article-I.D.: custom.757
Posted: Fri Jun 19 01:34:34 1987
Date-Received: Mon, 22-Jun-87 01:22:43 EDT
References: <7903@brl-adm.ARPA>
Organization: Custom Software Systems; Natick, MA
Lines: 39
Summary: Has to do with asynchronous processes

In article <7903@brl-adm.ARPA>, gaspar@ALMSA-1.arpa (Al Gaspar) writes:
> 
> We have several flavors of UN*X running at our installation:  Sperry 5000/80's
> running Sys V, a Plexus P60 running Sys V, a Vax 750 and a Vax 780 both
> running 4.2 BSD, and some Intel 310's running Xenix 3.0.  We have noticed a
> glitch in vi on the non-BSD implementations.  If you go into a large file (1000
> lines or so) with vi and send some of it out to a filter with !, you will
> corrupt the file.  

While at the USENIX conference I was discussing the addition of filters
to PC/VI with someone who visited the booth.  While I haven't totally
confirmed this persons opinion, it went something like this:
"Filtering a portion of the buffer is actually the combination of
writing the buffer to a pipe and reading the results back in.
To do this, UNIX VI forks itself and has one process do the write,
and the other do the read." I've tried doing such a filter using
VI Version 3.7 on a SV kernel on one terminal and running alot of
PS's on another and this does indeed seem to be what is happening.

This sounds like a nice idea.  The problem is that where
the data is coming from is taken from information contained in a
temporary file.  The data is likewise written to the buffer with
the appropriate updates to the *same* temporary file.  Given that
these two copies of VI are asynchronous, the VI writing to the
pipe is using data which has already been modified by the VI
reading from the pipe.  The result is that the temporary file,
and hence the file which will later be written out, is corrupted.

The reason this isn't seen with smaller portions of text has to
do with buffering done by the kernel, process scheduling and
some good luck!  The bottom line is that, given the way VI
implements this dual operation, the file is very likely to be
corrupted.  The fact that it doesn't happen when filtering small
portions of the buffer is a matter of luck.


Joe Boykin
Custom Software Systems
...necntc!custom!boykin