From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <z2gdf49a7371004290540g29060151k700bac13f78f34dc@mail.gmail.com>
References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net>
	<Pine.BSI.4.64.1004280750270.14121@malasada.lava.net>
	<4fa1305e0f56a0ef89c2e05320fa5997@coraid.com>
	<t2y13426df11004281142j3c735545k690dcfae6166cd4d@mail.gmail.com>
	<z2gdf49a7371004290540g29060151k700bac13f78f34dc@mail.gmail.com>
Date: Thu, 29 Apr 2010 08:18:36 -0700
Message-ID: <q2y13426df11004290818r3b875596s2c1af721347d58c@mail.gmail.com>
From: ron minnich <rminnich@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [9fans] A simple experiment
Topicbox-Message-UUID: 12888c36-ead6-11e9-9d60-3106f5b1d025

On Thu, Apr 29, 2010 at 5:40 AM, roger peppe <rogpeppe@gmail.com> wrote:

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

there are not replies -- the rstream is a reply. If the consumer is
slow packets are lost. That's life.


>
> in fact, how do you stop it deadlocking if the consumer is in
> fact waiting for one of those replies?

??

One Tstream. Lots of Rstreams. Zero interaction.

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

Yes.

ron