From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4d050f00d402e42d692b65ecad0677d4@plan9.bell-labs.com>
Date: Thu,  9 Mar 2006 13:40:09 -0500
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9p flush
In-Reply-To: <13edff48884a0e3146cf2454fa9c9336@vitanuova.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 105deff0-ead1-11e9-9d60-3106f5b1d025

When implementing 9P2000 in the old fileserver and fossil, there
were many places the protocol was not specific enough about what
to do. Most were cleared up. I dealt with this exact issue in fosssil
and it was decided the correct operation should be to reply to the
original operation if it has completed and then reply to the flush.
See /sys/src/cmd/fossil/9proc.c:^msgFlush for the lowdown.

--jim


On Thu Mar  9 13:30:43 EST 2006, rog@vitanuova.com wrote:
> 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.