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, knows 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 <leim...@gmail.com>: > > > 2010/10/14 Latchesar Ionkov <lu...@ionkov.net> >> >> 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. > You just have to eliminate the dependencies. > I can imagine having a few concurrent queues of "requests" in a client that > contain items with dependencies, and running those queues in a pipelined way > against a 9P server. > >> >> 2010/10/13 Venkatesh Srinivas <m...@acm.jhu.edu>: >> >> 2) you can't pipeline requests if the result of one request depends on >> >> 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 >> > >> > >
