From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8ccc8ba40706230745o50b1daf2ob558d6f0cdb835ef@mail.gmail.com>
Date: Sat, 23 Jun 2007 16:45:02 +0200
From: "Francisco J Ballesteros" <nemo@lsub.org>
To: lucio@proxima.alt.za,
	"Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] About 9P ...
In-Reply-To: <1182608849.24170.90.camel@simple>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <8ccc8ba40706221648i3d1ef70m6272c383d9f12983@mail.gmail.com>
	<7f6311b3aa8ba95b32892112e02878b4@coraid.com>
	<5d375e920706230601t6a0ca365pb532b6b07a874620@mail.gmail.com>
	<8ccc8ba40706230636r2c75ebc9m46bd28f08ebc1fe7@mail.gmail.com>
	<1182608849.24170.90.camel@simple>
Cc:
Topicbox-Message-UUID: 862094da-ead2-11e9-9d60-3106f5b1d025

Note that

if (stat()){
   open
   read
   close
}

is not new code. It's code in ls, 8c, mk, acme, etc. etc. etc.
The point is how to make that code work nicely across bad latency links.
But you do not want to change that code.

Also, there's no overhead if you don't use our stuff while "within the
building".

On 6/23/07, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Sat, 2007-06-23 at 15:36 +0200, Francisco J Ballesteros wrote:
>
> >
> > Now, say you have a program that does:
> > if (stat(afile)){
> >    open(afile)
> >    read(afile)
> >    close(afile)
> > }
> >
> So those are 9P's bad manners.  How many such idioms can one subsume
> into a "caching" process?  Because in my opinion it makes more sense, as
> I understand to have been Russ and Sape's proposal, to provide a
> sliding-window version of the above that sends all of them at once:
>
>         if (stat(afile), open(afile), read(afile), close(afile)) {
>           ...
>         } else {
>           perror ("");
>         }
>
> Somehow, we may need to differentiate the error return and it sure looks
> like programmers need to be aware of this implementation technique, but
> is it preferable to construct a specialised cache that knows to generate
> a get() whenever a stat() is performed?  The latter doesn't really scale
> to other potential scenarios and may add unwanted overheads.
>
> ++L
>
>
>