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: Mon, 31 Jul 2017 23:01:47 +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:47532 Date: 2017-07-31T23:01:47+02:00 List-Id: On 2017-07-31 20:08, Victor Porton wrote: > This is a question primarily to Dmitry A. Kazakov who (if I don't mistake) > proposed using lightweight tasks for co-routines. > > I do not quite understand how exactly it should be done: > > A task may contain several accepts with different names, but a co-routine > can contain only one type of entry and it is always with one variable with > "out" type (more conveniently represented as a function). First. A co-routine "task" may have any number of entries, of course. Second. The actual problem, how I see it, is that this is not an entry. If we consider the major use case, a producer-consumer pair, their interaction is impossible into an entry-call relation. The comfortable design is rather when the producer calls and so yields to the consumer when it has items to give away. The consumer calls and so yields to the producer when it needs another item to process. 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. > So should we standardize that tasks which serve as co-routines should have > entries with the same name only? No, see above. If a co-routine enters into a selective or other accept, it just yields. A delay alternative could be OK too. The effect would be that yielding from some other co-routine, basically when it terminates, would land there. Of course, there is no any guarantee about the actual waiting time, except that when yielding to the delay alternative, the "carrier" task is blocked until the timeout gets expired. > Isn't it more convenient to make them like "yield" keyword in Python? We can > for example require that all accepts have the name Yield and one out > argument. (However, see above about using functions instead.) Yield without a target is pointless. I see no case where it could be useful. When a co-routine yields it is only because it awaits for certain data. These data must be parameters of a call or else accept. Just yielding and letting the run-time to decide who's next is called *scheduling*, the thing we have for tasks, and don't want for co-routines. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de