From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 15 Oct 2010 16:59:02 +0200 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] =?utf-8?b?z4Bw?= Topicbox-Message-UUID: 65e063f4-ead6-11e9-9d60-3106f5b1d025 It's not just that you can stream requests or not. If you have caches in the path to the server, you'd like to batch together = (or stream or whatever you'd like to call that) requests so that if a client is reading a file and a single rpc suffices, the cache, in the worst case, kno= ws that it has to issue a single rpc to the server. Somehow, you need to group requests to retain the idea that a bunch of requests have some meaning as a whole. 2010/10/15 David Leimbach : > > > 2010/10/14 Latchesar Ionkov >> >> It can't be dealt with the current protocol. It doesn't guarantee that >> Topen will be executed once Twalk is done. So can get Rerrors even if >> Twalk succeeds. >> > > It can be dealt with if the scheduling of the pipeline is done properly. > =C2=A0You just have to eliminate the dependencies. > I can imagine having a few concurrent queues of "requests" in a client th= at > contain items with dependencies, and running those queues in a pipelined = way > against a 9P server. > >> >> 2010/10/13 Venkatesh Srinivas : >> >> 2) you can't pipeline requests if the result of one request depends o= n >> >> the >> >> result of a previous. for instance: walk to file, open it, read it, >> >> close >> >> it. >> >> if the first operation fails, then subsequent operations will be >> >> invalid. >> > >> > Given careful allocation of FIDs by a client, that can be dealt with - >> > operations on an invalid FID just get RErrors. >> > >> > -- vs >> > >> > >