From adc93f6097615f16d57e8a24a256302f2144ec4e Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 17:37:50 +0000 Subject: cut out the html - they're going to cause diffing problems. --- man/man9/flush.html | 98 ----------------------------------------------------- 1 file changed, 98 deletions(-) delete mode 100644 man/man9/flush.html (limited to 'man/man9/flush.html') diff --git a/man/man9/flush.html b/man/man9/flush.html deleted file mode 100644 index 20544557..00000000 --- a/man/man9/flush.html +++ /dev/null @@ -1,98 +0,0 @@ - -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