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!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Lightweight tasks to implement co-routines? Date: Tue, 1 Aug 2017 08:47:52 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:47543 Date: 2017-08-01T08:47:52+02:00 List-Id: On 2017-08-01 06:56, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:olo5rp$dp0$1@gioia.aioe.org... >> On 2017-07-31 20:08, Victor Porton wrote: > ... >> I have a vague idea that it should be an entry of some ad-hoc fake >> protected object that would glue both calls together, or maybe an entry of >> the "carrier" task. But I don't know how to make this easy to use and >> encapsulated without exposing to other contexts. > > Tucker Taft is proposing a construct called a "channel" for this purpose. It > sounds interesting, but there are so few details it is impossible to tell. > There is an AI for it (AI12-0197-4), but it is empty pending a real proposal > from Tucker. Yes, at least the use case is same. One very important thing though. The construct cannot be statically nested as suggested. Consider the case when one producer distributes items among several consumers. As a practical example take a multiple socket select in the producer that then yields to one of the consumers to handle the active socket or else to process socket I/O data. 1. You don't know in advance how many consumers (connections) there will be. 2. There are multiple groups of identical consumers. I am sure there could be cases with multiple producers as well. This is why I thought that a task would be a much better way to express co-routine than some nested block. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de