On 28 April 2010 19:42, ron minnich <rminn...@gmail.com> 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 saw 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.
