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. > From: quans...@quanstro.net > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Tue Apr 21 16:11:28 CET 2009 > Subject: Re: [9fans] Plan9 - the next 20 years > > On Tue Apr 21 10:05:43 EDT 2009, rogpe...@gmail.com wrote: > > 2009/4/21 erik quanstrom <quans...@quanstro.net>: > > > what is the important use case of flush and why is this > > > so important that it drives the design? > > > [...] > > "The 9P protocol must run above a reliable transport protocol with > > delimited messages. [...] > > UDP [RFC768] does not provide reliable in-order delivery." > > (is this the canonical reference for this requirement? the man page > > doesn't seem to say it) > > great post, but i still don't understand why the > protocol is designed around flush semantics. > > all your examples have to do with the interaction > between flush and something else. why is flush > so important? what if we just ignored the response > we don't want instead? > > - erik
