From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net> <4fa1305e0f56a0ef89c2e05320fa5997@coraid.com> Date: Thu, 29 Apr 2010 13:40:53 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] A simple experiment Topicbox-Message-UUID: 122966b6-ead6-11e9-9d60-3106f5b1d025 On 28 April 2010 19:42, ron minnich wrote: > We did a simple experiment recently: added a new 9p type called > Tstream, because this issue of streams vs. transactions has been > bugging me for years. The semantics are simple: it's a lot like Tread > (almost same packet) but a single Tstream results in any number of > Rstreams, until you hit no more data (/dev/mouse) or maybe EOF > (/usr/rminnich/movie). Andrey tossed a sample implementation into > newsham's 9p library. We =C2=A0saw a 27x improvement in performance from > calgary to sandia for a big file. Fcp did not come close. what happens if the consumer is slow and the Rstream writer blocks? how do you stop all the other replies on the connection waiting for the consumer to get on with it? in fact, how do you stop it deadlocking if the consumer is in fact waiting for one of those replies? i suppose this comes down to what the API looks like. isochronous might be easier, as a slow reader is a bad reader so you could just throw away some data.