On Mon, Apr 20, 2009 at 11:35 AM, erik quanstrom <quanstro@coraid.com>wrote:

> > I thought 9p had tagged requests so you could put many requests in flight
> at
> > once, then synchronize on them when the server replied.
> >
> > Maybe i misunderstand the application of the tag field in the protocol
> then?
> >
> > Tread tag fid offset count
> >
> > Rread tag count data
>
> without having the benefit of reading ken's thoughts ...
>
> you can have 1 fd being read by 2 procs at the same time.
> the only way to do this is by having multiple outstanding tags.


I thought the tag was assigned by the client, not the server (since it shows
up as a field in the T message), and that this meant it's possible for one
client to put many of it's own locally tagged requests into the server, and
wait for them in any order it chooses.

It would not make sense to me to have to have a global pool of tags for all
possible connecting clients.

Again, this may just be my ignorance, and the fact that I've never
implemented a 9p client or server myself.  (haven't had a need to yet!)


>
>
> i think the complaint about 9p boils down to ordering.
> if i want to do something like
>        cd /sys/src/9/pc/ ; cat sdata.c
> that's a bunch of walks and then an open and then a read.
> these are done serially, and each one takes 1rtt.
>

Some higher operations probably require an ordering.  But there's no reason
you could do two different sequences of walks, and a read concurrently is
there?



>
> - erik
>
>