Re: [9fans] Plan9 - the next 20 years

[roger peppe <rogpeppe@gmail.com>]

2009/4/21 erik quanstrom <quanstro@quanstro.net>:
> isn't the tag space per fid?

no, otherwise every reply message (and Tflush) would include a fid too;
moreover Tversion doesn't use a fid (although it probably doesn't
actually need a tag)

> a variation on the tagged queuing flush
> cache would be to force the client to make sure that reordered
> flush tags aren't a problem.  it would not be very hard to ensure that
> tag "overlap" does not happen.

the problem is not in tag overlap, but in the fact that
the server may or may not already have serviced the
request when it receives a Tflush.
the client can't know this - the only way
it knows if the transaction actually took place is if the
reply to the request arrives before the reply to the flush.

this "race" is, i think, an inherent part of allowing
requests to be aborted. the flush protocol is probably the most
complex and the most delicate part of 9p, but it's also one
of the most useful, because reinventing it correctly is
hard and it solves a oft-found problem - how do i tear
down a request that i've already started?

plan 9 and inferno rely quite heavily on having flush,
and it's sometimes notable when servers don't implement it.
for instance, inferno's file2chan provides no facility
for flush notification, and wm/sh uses file2chan; thus if you
kill a process that's reading from wm/sh's /dev/cons,
the read goes ahead anyway, and a line of input is lost
(you might have seen this if you ever used os(1)).

that's aside from the issue of resource-leakage that
nemo points out.

the idea with my proposal is to have an extension that
changes as few of the semantics of 9p as possible:

C->S Tsequence tag=1 sid=1
C->S Topen tag=2 sid=1 fid=20 mode=0
C->S Tread tag=3 sid=1 fid=20 count=8192
C->S Tclunk tag=4 sid=1
S->C Rsequence tag=1
S->C Ropen tag=2 qid=...
S->C Rread tag=3 data=...
S->C Rclunk tag=4

would be exactly equivalent to:

C->S Topen tag=2 fid=20 mode=0
S->C Ropen tag=2 qid=...
C->S Tread tag=3 fid=20 count=8192
S->C Rread tag=3 data=...
C->S Tclunk tag=4
S->C Rclunk tag=4

and the client-side interface could be designed so
that the client code is the same regardless of whether
the server implements Tsequence or not (for instance,
in-kernel drivers need not implement it).

thus most of the code base could remain unchanged,
but everywhere gets the benefit of latency reduction from a few core
code changes (e.g. namec).