From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Asynchronous channels in Ada
Date: Sun, 21 Feb 2016 19:30:32 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <nadrmm$mk6$1@dont-email.me>
References: <dd09d409-78ef-4cf5-9557-e38b7042e3ab@googlegroups.com>
 <c850cac4-40d4-40c3-a850-4508e85f6460@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 22 Feb 2016 02:27:36 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b23ebdd8f1375266fb11e3d213ad4434";
	logging-data="23174"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19Bdg8d4e/31hx26giK11nsbDp2rgPXri0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
In-Reply-To: <c850cac4-40d4-40c3-a850-4508e85f6460@googlegroups.com>
X-Mozilla-News-Host: news://freenews.netfront.net
Cancel-Lock: sha1:20v7kJPykx4KBXxKnw/DGz5bUZI=
Xref: news.eternal-september.org comp.lang.ada:29582
Date: 2016-02-21T19:30:32-07:00
List-Id: <comp.lang.ada>

On 02/21/2016 03:57 PM, Hadrien Grasland wrote:
> 
> Let's put ourself in a typical usage scenario where you have a producer task
> and a consumer task, the former producing a stream of identically typed data
> that is read by the other. This producer/consumer pair may be part of a
> fairly large and complex data processing pipeline, such as a compiler
> frontend.
> 
> Now, something goes wrong on the producer side, for any reason, which
> prevents this task from correctly producing its next data packet. Yet the
> consumer is expecting said packet. One can then imagine a number of options
> for the producer :

Typically, such designs are used so the consumer doesn't need to know or care
about what happens with the producer, and so there's no need for anything
special about the queue or the data passed via it. Certainly this is the
assumption that most general-purpose solutions will take. If you have specific
needs that such solutions don't address, you will probably need to create a
specific solution.

That said, it would be very easy to add a Boolean value to the PragmARC blocking
protected queues that would cause an exception in a consumer when it next
attempts to get a value from the queue.

-- 
Jeff Carter
"Little blondes with long hair and short skirts and
boots and big chests and bright, witty, and perceptive."
Play It Again, Sam
128