From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Tue, 21 Apr 2009 10:50:18 -0400 To: 9fans@9fans.net In-Reply-To: <6fca5b4a2b0c1df84043eddf28ce3f52@lsub.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: ed24f084-ead4-11e9-9d60-3106f5b1d025 On Tue Apr 21 10:34:34 EDT 2009, nemo@lsub.org wrote: > Well, if you don't have flush, your server is going to keep a request > for each process that dies/aborts. If requests always complete quite > soon it's not a problem, AFAIK, but your server may be keeping the > request to reply when something happens. Also, there's the issue that > the flushed request may have allocated a fid or some other resource. > If you don't agree that the thing is flushed you get out of sync with the > client. > > What I mean is that as soon as you get concurrent requests you really > ned to implement flush. Again, AFAIK. isn't the tag space per fid? a variation on the tagged queuing flush cache would be to force the client to make sure that reordered flush tags aren't a problem. it would not be very hard to ensure that tag "overlap" does not happen. if the problem with 9p is latency, then here's a decision that could be revisisted. it would be a complication, but it seems to me better than a http-like protocol, bundling requets together or moving to a storage- oriented protocol. - erik