From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190704102358v75f5be2ek4947da758c6e1218@mail.gmail.com> Date: Wed, 11 Apr 2007 16:58:57 +1000 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P2000 and p9p In-Reply-To: <20070411031014.25A7D1E8C1C@holo.morphisms.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <461C45A4.3060909@tecmav.com> <20070411031014.25A7D1E8C1C@holo.morphisms.net> Topicbox-Message-UUID: 44ed1b64-ead2-11e9-9d60-3106f5b1d025 can i say that EOD is useless on synthesized files. may be good on readonly stuff. i hate the extra read of 0 but get over it. as presto once said "are you just whining or preposing a solution?". brucee On 4/11/07, Russ Cox wrote: > > 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 > >