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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Received: by 2002:a0c:d1dd:: with SMTP id k29mr6842127qvh.110.1571169834857;
        Tue, 15 Oct 2019 13:03:54 -0700 (PDT)
X-Received: by 2002:aca:3183:: with SMTP id x125mr288707oix.78.1571169834559;
 Tue, 15 Oct 2019 13:03:54 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!o24no490668qtl.0!news-out.google.com!q23ni898qtl.1!nntp.google.com!o24no490660qtl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 15 Oct 2019 13:03:54 -0700 (PDT)
In-Reply-To: <5da620ec$0$21604$426a74cc@news.free.fr>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=146.5.2.231;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.231
References: <5da4cf81$0$20312$426a74cc@news.free.fr>
 <qo2k18$4hh$1@gioia.aioe.org>
 <5da4e182$0$20321$426a74cc@news.free.fr>
 <a0c9b607-dab3-4e0b-a249-aea8c30c99bc@googlegroups.com>
 <5da620ec$0$21604$426a74cc@news.free.fr>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5cb607c5-3ea4-439f-9310-337aad7ae8d5@googlegroups.com>
Subject: Re: How to transfer Class-Wide object to a Task ?
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Tue, 15 Oct 2019 20:03:54 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader01.eternal-september.org comp.lang.ada:57294
Date: 2019-10-15T13:03:54-07:00
List-Id: <comp.lang.ada>

One of the nice things about a stream-based design is that (at least theoretically) is that your source is abstracted away -- it doesn't matter if your source is keyboard or radio-receiver or disk or the destination is screen or radio-transmitter or disk.

So, with such a design you could have a system where items are stored in a cache which might be dumped-to/retrieved-from disk, as well as real-time item-generation,  as a 'producer' and where the 'consumer' processes the items.

This sort of design could allow for a high-speed and low-speed channel [to the consumer], as well as a system where [work-]items could be saved -- say for a node restart in certain [distributed] cases.