Re: [9fans] Plan9 - the next 20 years

[erik quanstrom <quanstro@quanstro.net>]

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