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
