2009/4/21 erik quanstrom <quans...@quanstro.net>: >> 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. i 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.
