From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 17 Oct 2005 09:03:22 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: some Plan9 related ideas In-Reply-To: <20051017124559.GB29494@server4.lensbuddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19450.1125421653@piper.nectar.cs.cmu.edu> <600308d60508301033589f9f55@mail.gmail.com> <20051017071433.GA29494@server4.lensbuddy.com> <20051017124559.GB29494@server4.lensbuddy.com> Topicbox-Message-UUID: 9b3a92f0-ead0-11e9-9d60-3106f5b1d025 > > > 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