From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 13 Oct 2010 16:15:09 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e68ee136c06e61049287c32d Subject: Re: [9fans] =?iso-8859-7?q?=F0p?= Topicbox-Message-UUID: 63d6e0a6-ead6-11e9-9d60-3106f5b1d025 --0016e68ee136c06e61049287c32d Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable 2010/10/13 roger peppe > 2010/10/13 David Leimbach : > > I guess I do not understand how 9p doesn't support pipelining. All > > requests are tagged and can be dealt with between client and server in > > any order right? > > two issues (at least): > > 1) concurrently sent requests can be reordered (they're serviced in > separate > threads on the server) which means that, when reading from a streaming fi= le > which ignores file offsets, you don't necessarily get data back in the > order that > you asked for it. > > 2) you can't pipeline requests if the result of one request depends on th= e > 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. > I guess I'm trying to imagine how specifically you could pipeline, not the general ways in which pipelining will fail with 9P. > > > > > On Wednesday, October 13, 2010, Eric Van Hensbergen > wrote: > >> For folks interested in more info on the =F0p portion of Noah's Osprey > talk, > >> Anant's thesis is available online: http://proness.kix.in/misc/ > =F0p-v2.pdf > >> > >> -eric > >> > >> > > > > > > --0016e68ee136c06e61049287c32d Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable

2010/10/13 roger peppe <rogpeppe@gmail.com>
2010/10/13 David Leimbach <leimy2k@= gmail.com>:
> I guess I do not understand how 9p doesn't suppo= rt pipelining. =A0 All
> requests are tagged and can be dealt with between client and server in=
> any order right?

two issues (at least):

1) concurrently sent requests can be reordered (they're serviced in sep= arate
threads on the server) which means that, when reading from a streaming file=
which ignores file offsets, you don't necessarily get data back in the<= br> order that
you asked for it.

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 i= t.
if the first operation fails, then subsequent operations will be invalid.

I guess I'm trying to imagine how sp= ecifically you could pipeline, not the general ways in which pipelining wil= l fail with 9P.


=A0

>
> On Wednesday, October 13, 2010, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> For folks interested in more info on the =F0p portion of Noah'= s Osprey talk,
>> Anant's thesis is available online: http://proness.kix.in/misc/=F0p-v2.pdf<= br> >>
>> =A0=A0 =A0 =A0-eric
>>
>>
>
>


--0016e68ee136c06e61049287c32d--