From mboxrd@z Thu Jan  1 00:00:00 1970
Subject: Re: [9fans] About 9P ...
From: Lucio De Re <lucio@proxima.alt.za>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
In-Reply-To: <8ccc8ba40706230636r2c75ebc9m46bd28f08ebc1fe7@mail.gmail.com>
References: <8ccc8ba40706221648i3d1ef70m6272c383d9f12983@mail.gmail.com>
	<7f6311b3aa8ba95b32892112e02878b4@coraid.com>
	<5d375e920706230601t6a0ca365pb532b6b07a874620@mail.gmail.com>
	<8ccc8ba40706230636r2c75ebc9m46bd28f08ebc1fe7@mail.gmail.com>
Content-Type: text/plain
Date: Sat, 23 Jun 2007 16:27:29 +0200
Message-Id: <1182608849.24170.90.camel@simple>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 861c08a2-ead2-11e9-9d60-3106f5b1d025

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