From 78e51a8c6678b6e3dff3d619aa786669f531f4bc Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 03:45:44 +0000 Subject: checkpoint --- man/man9/flush.html | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 man/man9/flush.html (limited to 'man/man9/flush.html') diff --git a/man/man9/flush.html b/man/man9/flush.html new file mode 100644 index 00000000..20544557 --- /dev/null +++ b/man/man9/flush.html @@ -0,0 +1,98 @@ + +flush(9P) - Plan 9 from User Space + + + + +
+
+
FLUSH(9P)FLUSH(9P) +
+
+

NAME
+ +
+ + flush – abort a message
+ +
+

SYNOPSIS
+ +
+ + size[4] Tflush tag[2] oldtag[2]
+ size[4] Rflush tag[2]
+ +
+

DESCRIPTION
+ +
+ + 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.
+ +
+

ENTRY POINTS
+ +
+ + The 9pclient(3) library does not generate flush transactions.. + 9pserve(4) generates flush transactions to cancel transactions + pending when a client hangs up.
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + -- cgit v1.2.3