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

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Tue, 21 Apr 2009 10:50:18 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> 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 a process crashes, who sends the Tflush?  The server must
clean up without Tflush if a connection closes unexpectedly.

I thought the whole point of Tflush was to cancel a
potentially expensive operation (ie when the user hits the
interrupt key). You still have to cleanup.

> >                                    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.

Why does it matter?

> 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.

Can you explain why is it better than bundling requests
together?  Bundling requests can cut out a few roundtrip
delays, which can make a big difference for small files.
What you are talking about seems useful for large files [if I
understand you correctly].  Second, 9p doesn't seem to
restrict any replies other than Rflushes to be sent in order.
That means the server can still send Rreads in any order but
if a Tflush is seen, it must clean up properly.  The
situation is analogous what happens in an an OoO processor
(where results must be discarded in case of exceptions and
mis-prediction on branches).