|
When the response to a request is no longer needed, such as when
a user interrupts a process doing a read(9p), a Tflush request
is sent to the server to purge the pending response. The message
being flushed is identified by oldtag. The semantics of flush
depends on messages arriving in order.
The server should answer the flush message immediately. If it
recognizes oldtag as the tag of a pending transaction, it should
abort any pending response and discard that tag. In either case,
it should respond with an Rflush echoing the tag (not oldtag)
of the Tflush message. A Tflush can never be
responded to by an Rerror message.
The server may respond to the pending request before responding
to the Tflush. It is possible for a client to send multiple Tflush
messages for a particular pending request. Each subsequent Tflush
must contain as oldtag the tag of the pending request (not a previous
Tflush). Should multiple Tflushes be
received for a pending request, they must be answered in order.
A Rflush for any of the multiple Tflushes implies an answer for
all previous ones. Therefore, should a server receive a request
and then multiple flushes for that request, it need respond only
to the last flush.
When the client sends a Tflush, it must wait to receive the corresponding
Rflush before reusing oldtag for subsequent messages. If a response
to the flushed request is received before the Rflush, the client
must honor the response as if it had not been flushed, since the
completed request may signify a state
change in the server. For instance, Tcreate may have created a
file and Twalk may have allocated a fid. If no response is received
before the Rflush, the flushed transaction is considered to have
been canceled, and should be treated as though it had never been
sent.
Several exceptional conditions are handled correctly by the above
specification: sending multiple flushes for a single tag, flushing
after a transaction is completed, flushing a Tflush, and flushing
an invalid tag.
|
