From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Fri, 15 Oct 2010 18:40:55 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-xsqvgxofyjjttombtcouadguqn" Subject: Re: [9fans] =?utf-8?b?z4Bw?= Topicbox-Message-UUID: 6615bc2a-ead6-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-xsqvgxofyjjttombtcouadguqn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit fork! -- cinap --upas-xsqvgxofyjjttombtcouadguqn Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 15 Oct 2010 16:34:13 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx009) with SMTP; 15 Oct 2010 18:34:13 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1P6nCI-0000M3-TM; Fri, 15 Oct 2010 16:31:58 +0000 Received: from mail-fx0-f49.google.com ([209.85.161.49]) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1P6nCH-0000Lf-8e for 9fans@9fans.net; Fri, 15 Oct 2010 16:31:57 +0000 Received: by fxm15 with SMTP id 15so639713fxm.36 for <9fans@9fans.net>; Fri, 15 Oct 2010 09:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=GTWy5iciToIx5FY90SAOq5BA75H3TOwqAmCDpTlZORc=; b=u+pKXoH0REGYlniYNFegZ4mTPRfafp0KzACvdmIavLyY3+U+rLQvnbBoQL2SDIdg94 7AX6CaYcNltcYr0tV7HFwc5hSuFjSNB2kHwwp/ewpw3RnLq48JGyO1R8ySqr1pIEXWFg Z0Eor4fHYaZnxkQnmwV7nSNlJ4rV87SxzPlsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=QXO2AQDibHdu7FqGC01FzWoplU0Cxb/7psr+RYC4zWTve+CLmNzxotZ1lAveK/Go2u R8aGTaF21UUpVZ+7mGbMkm/1DUi54s9UHLcPbLZ49LQCfRVsv0EnnJ+TrFi1xLo0of08 S7NUZy7N+nIAFNgiYo4jMLPgVdwGCcSnm0oHc= MIME-Version: 1.0 Received: by 10.239.191.140 with SMTP id b12mr74095hbi.36.1287160307819; Fri, 15 Oct 2010 09:31:47 -0700 (PDT) Received: by 10.239.151.210 with HTTP; Fri, 15 Oct 2010 09:31:47 -0700 (PDT) In-Reply-To: <10af1064d3ac35a8d2f62214d5eec485@gmx.de> References: <10af1064d3ac35a8d2f62214d5eec485@gmx.de> Date: Fri, 15 Oct 2010 10:31:47 -0600 X-Google-Sender-Auth: gqB6H_uYWvQ66Ma7TuzESSrEqy4 Message-ID: From: Latchesar Ionkov To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] =?iso-8859-7?q?=F0p?= X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p6i75npGen84eVAEFK/syJmiNoEBJhgjYKpglu1TZLLw7xMZnJMXwBFy+Sxe D/AUQGQOurK3ezVJqUBFH0uN5pjmWoMfpyHp50EZ60/Y6hM43eiKLTaE/W0dI7nIn8+pr4SzneyH Jeytg==V1; What if the data your process needs is located on more than one server? Play ping-pong? Thanks, Lucho 2010/10/15 : > i wonder if making 9p work better over high latency connections is > even the right answer to the problem. =A0the real problem is that the > data your program wants to work on in miles away from you and > transfering it all will suck. =A0would 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... =A0but it poped up again when i read the "bring the computation > to the data" point from the ospray talk. > > -- > cinap > > > ---------- Forwarded message ---------- > From:=A0Francisco J Ballesteros > To:=A0Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Date:=A0Fri, 15 Oct 2010 16:59:02 +0200 > Subject:=A0Re: [9fans] =F0p > 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 togethe= r (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, k= nows > 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. >> =A0You just have to eliminate the dependencies. >> I can imagine having a few concurrent queues of "requests" in a client t= hat >> 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 = 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 >>> > >>> >> >> > > --upas-xsqvgxofyjjttombtcouadguqn--