From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 17 Oct 2005 14:22:08 +0100 From: Uriel To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: some Plan9 related ideas Message-ID: <20051017132208.GC29494@server4.lensbuddy.com> References: <19450.1125421653@piper.nectar.cs.cmu.edu> <600308d60508301033589f9f55@mail.gmail.com> <20051017071433.GA29494@server4.lensbuddy.com> <20051017124559.GB29494@server4.lensbuddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Topicbox-Message-UUID: 9b4102d4-ead0-11e9-9d60-3106f5b1d025 On Mon, Oct 17, 2005 at 09:03:22AM -0400, Russ Cox wrote: > I redefined use of the same tag to mean "you have to finish the > previous message with this tag before processing this message", > so that if you send a Topen followed by a Tread and the open > blocks for whatever reason (disk i/o, say), the remote server > doesn't try to run the Tread and send back a "fid not in use" > error or some such. Yes, that would be a problem with threaded servers, as you indicated. > > Could you explain with more detail how it would work from the (threaded) > > server POV? I was thinking that the server could use the fid to avoid > > threads stepping into each other, and still avoid having to change the > > protocol at all... > > The threaded server would just have a list of requests associated with > each tag instead of a single request. When it finishes one it can move > on to the next. > > Under the current protocol you are not allowed to send a Tread request > using a fid that the server has not acknowleged via Rattach or Ropen. Ah! I was not aware of this restriction. > So your approach still requires redefining the protocol. Also I might have > multiple I/Os going on and not care what order they get handled. > Synchronization based on the fid changes current situations. Basing it > on the tag uses what were previously illegal situations. Good point. I understand better now the reasons for your approach. > > And I'm still curious what kernel changes nemo was talking about. > > Read his post where he talks about mount -U. > > If you mean readf and writef, those weren't kernel changes. > They were the obvious library wrappers. Sorry, I was not clear enough, I was referring to this: "We added two (library) calls readf and writef that perform file I/O besides resolving the name. We found ourselves calling them a lot, because in many cases it's very convenient. They would be an opportunity to "batch" walk/open/read(s)/clunk, which happen a lot. However, this would require changing the kernel (even more than we did for Plan B)." (BTW, I get the feeling that readf/writef might be convenient, but you could easily end up sending superfluous walks/opens/clunks) And I'm not convinced by Plan B's style of 'one value per file' for (almost?) everything, maybe it smells to me too much of linux's sysfs :) (Nothing wrong with 'one value per file' where it makes sense, I just don't think it works well as a general rule) uriel