2009/4/21 erik quanstrom <quans...@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).
