From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <13edff48884a0e3146cf2454fa9c9336@vitanuova.com>
To: 9fans@cse.psu.edu
Date: Thu,  9 Mar 2006 18:30:37 +0000
From: rog@vitanuova.com
In-Reply-To: <1cc43661a51e16266fb8b944cd1827ec@swtch.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] 9p flush
Topicbox-Message-UUID: 105a0e6c-ead1-11e9-9d60-3106f5b1d025

i've been implementing some generic mechanisms for serving 9p.

from flush(5):

          The server must answer the flush message immediately.

which i interpret to mean "no other messages should be processed in
the meantime".

how important is this?

the problem is that in a multithreaded environment, the thread
performing a request must be notified that it has been flushed, and
given a chance to try and abort its current action.

it it happens that the action has already completed, then it should
be allowed to reply before the flush reply, thus letting the client
know correctly about the state change.  the problem is that this means
that there can be an arbitrary delay before the flush is replied to
(although i'm still ensuring that flush messages are answered in
order),

does doing things this way break any aspect of the protocol?  if it
does not, then might i suggest that that line of the manual page be
changed to:

	The server must answer the flush message as soon as possible.