Re: [9fans] πp

[cinap_lenrek@gmx.de]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

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.

--
cinap

[-- Attachment #2: Type: message/rfc822, Size: 5318 bytes --]

From: Francisco J Ballesteros <nemo@lsub.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] πp
Date: Fri, 15 Oct 2010 16:59:02 +0200
Message-ID: <AANLkTin-8v4UZkxt1oYzS=mkkr79cRzS3T1EJyiKMCzN@mail.gmail.com>

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 <leimy2k@gmail.com>:
>
>
> 2010/10/14 Latchesar Ionkov <lucho@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 <me@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
>> >
>>
>
>