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
