Re: [9fans] 9p flush

["Russ Cox" <rsc@swtch.com>]

The only requirement is that flush is handled in a timely fashion.
It can't block indefinitely and it shouldn't block on anything
it doesn't have to.  For example, in the worm file server,
if you flush a read, the file server doesn't interrupt the read
but it does mark the read as flushed and reply to the flush
immediately.  It will then not reply to the read once the worm
data arrives.  It would be as correct, though more frustrating
to users typing DEL, if the flush just waited on the worm data.

It's not the case that you can't reply to other messages
between receiving a Tflush and sending the Rflush.
That would be unreasonable since there might be
R-messages in flight that would appear to have been
sent between the two events.

The ultimate reason for all this is that if you have a process
blocked on a 9P message and it gets interrupted, the kernel
sends a Tflush and cannot let the process handle the interrupt
until the Rflush is received.  So it shouldn't take arbitrarily long,
and the faster you can reply the better.

The kernel must wait for the Rflush to find out whether the
op is going to complete successfully.  For example, if you
flush a Twalk, it's important to know whether the Rwalk
comes back or not.  If you get the Rwalk before the Rflush,
then the walk succeeded and the fid has moved (or a new fid
created).  If you get the Rflush with no Rwalk, you know the
Rwalk isn't coming and that the walk never happened.

You can wait for the Rwhatever to go out before you respond
to the Rflush if you want, as long as it's not going to block
indefinitely.  This is what lib9p will do for you if you don't
give a flush handler in the Srv structure.

It is more important to get the semantics right than the timing.

Russ