From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <37ef730aacf5a0b86b77caaa538afd8d@vitanuova.com>
To: paurea@gmail.com, 9fans@cse.psu.edu
Subject: Re: [9fans] afid and fd, mapping from user space
Date: Thu,  7 Jul 2005 03:33:42 +0100
From: rog@vitanuova.com
In-Reply-To: <599f06db050701152062c908fe@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 626db358-ead0-11e9-9d60-3106f5b1d025

> I am porting Recover to 4e. Recover is a filesystem which speaks
> 9P with two ends, a server and a client. When a connection falls down
> it pushes the state and restarts the pending requests, so you don't
> see a hung channel any more if your connection falls down.

i did something like this for inferno, but couldn't work out what was
the best thing to do about non-idempotent 9p transactions: if the
connection is lost before the reply to such a transaction is received,
what is the correct course of action?  the client can't know whether the
transaction has actually taken place on the server.

examples of such requests:

	create
	wstat (rename)
	write to an append-only file
	any operation on a non-standard filesystem (e.g. writing a ctl file)

problems arising from this kind of thing will be
rare, but all the more insidious when they do actually happen.

in the end, i decided to make such requests yield Rerror("operation possibly failed"),
but i have a niggling feeling that the whole approach is wrong.

thoughts?