From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <04c811208183aa176e6d88f5775f1ed6@quanstro.net> References: <04c811208183aa176e6d88f5775f1ed6@quanstro.net> Date: Tue, 21 Apr 2009 19:14:33 +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: ee940572-ead4-11e9-9d60-3106f5b1d025 2009/4/21 erik quanstrom : >> i was trying to point out that if you try to >> ignore the issue by removing flush from the >> protocol, you'll get a system that doesn't work so smoothly. > > your failure cases seem to rely on poorly chosen tags. > i wasn't suggesting that flush be eliminated. =C2=A0i was > thinking of ways of keeping flush self-contained. my failure cases were based around supposing that 9p messages could be re-ordered in transit, as a response to maht's post. they can't, so there's no problem, as far as i can see. my proposal barely affects the flush semantics (there'd be an additional rule that flushing a Tsequence aborts the entire sequence, but i think that's it) the race case that i was talking about cannot be avoided by remembering old flushes. the problem is that an action (which could involve any number of irreversible side-effects) might have been performed at the instant that you tell it to abort. the semantics of flush let you know if you got there in time to stop it.