> > > I was reading old archives, and I'm probably a bit dense; but what is > > > the reason to use the same tag for the three messages?
> > The reason is you don't have to wait for the response to the first > > before sending the second and third, avoiding two round trip times. > Yes, but what I didn't understand is why you needed to use the same tag, > I thought you could do this without chaning the protocol. 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. > 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. 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. > 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. Russ
