From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6fca5b4a2b0c1df84043eddf28ce3f52@lsub.org> To: 9fans@9fans.net From: "Fco. J. Ballesteros" Date: Tue, 21 Apr 2009 16:33:03 +0200 In-Reply-To: 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: ed20bb18-ead4-11e9-9d60-3106f5b1d025 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: quanstro@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, rogpeppe@gmail.com wrote: > > 2009/4/21 erik quanstrom : > > > 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