From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9P2000 and p9p
From: "Russ Cox" <rsc@swtch.com>
Date: Tue, 10 Apr 2007 23:10:12 -0400
In-Reply-To: <461C45A4.3060909@tecmav.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20070411031014.25A7D1E8C1C@holo.morphisms.net>
Topicbox-Message-UUID: 44d70a5e-ead2-11e9-9d60-3106f5b1d025

> There is no correlation between read and write ops executed on different 
> machines to the same file server, wherever it is running on. 

This is not true.

Suppose two programs running on two different machines
are communicating directly but also using a shared file server.

Then program A could write something to a file, tell program B
there was new data in the file, and program B could read it.
Repeat.  You get the same write, read, write, read sequence
I gave before, but without any central kernel that knows enough
to second-guess the EOD tag on the first read response -- the
reads happen using one machine, the writes using another.

You are proposing a clumsy fix to a problem that you haven't
actually demonstrated to exist.  The extra read is just not 
costly enough in practice to justify the extra complexity.

You are already doing Twalk Topen Tread Tclunk.  A second 
Tread won't hurt very much.  If you really care about minimizing
the number of requests, you'd do better to have a single "events"
file that got opened once and then polled (with blocking reads)
to get information out of the device.

Russ