2010/10/15 <cinap_len...@gmx.de> > i wonder if making 9p work better over high latency connections is > even the right answer to the problem. the real problem is that the > data your program wants to work on in miles away from you and > transfering it all will suck. would it not be cool to have a way to > teleport/migrate your process to a cpu server close to the data? > > i know, this is a crazy blue sky idea that has lots of problems on its > own... but it poped up again when i read the "bring the computation > to the data" point from the ospray talk. > > I thought migrating processes was part of Osprey's story :-).
> -- > cinap > > > ---------- Forwarded message ---------- > From: Francisco J Ballesteros <n...@lsub.org> > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Date: Fri, 15 Oct 2010 16:59:02 +0200 > Subject: Re: [9fans] πp > 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 > >> > > >> > > > > > >
