From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <6fca5b4a2b0c1df84043eddf28ce3f52@lsub.org> Date: Tue, 21 Apr 2009 17:03:07 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: edbe8140-ead4-11e9-9d60-3106f5b1d025 2009/4/21 erik quanstrom : > 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. =C2=A0it would not be very hard to ensure th= at > 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=3D1 sid=3D1 C->S Topen tag=3D2 sid=3D1 fid=3D20 mode=3D0 C->S Tread tag=3D3 sid=3D1 fid=3D20 count=3D8192 C->S Tclunk tag=3D4 sid=3D1 S->C Rsequence tag=3D1 S->C Ropen tag=3D2 qid=3D... S->C Rread tag=3D3 data=3D... S->C Rclunk tag=3D4 would be exactly equivalent to: C->S Topen tag=3D2 fid=3D20 mode=3D0 S->C Ropen tag=3D2 qid=3D... C->S Tread tag=3D3 fid=3D20 count=3D8192 S->C Rread tag=3D3 data=3D... C->S Tclunk tag=3D4 S->C Rclunk tag=3D4 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).