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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Fri, 17 Jun 2016 18:46:32 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: w/2xSGckQeJEFvqsQFNodA.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:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30771 Date: 2016-06-17T18:46:32+02:00 List-Id: On 2016-06-17 18:18, Niklas Holsti wrote: > - First, please do not redefine the word "task", even in the qualified > form "asynchronous task". It is quite confusing, in the Ada context. Yes. > - Second, I question the terminology of "user thread". The "events", or > "asynchronous tasks", are not "threads" in the sense of keeping their > own machine-level control-flow state; they are automata that are invoked > from the "executors" through a single "Run" operation. If some > control-flow state must be kept between invocations of "Run", the > "asynchronous task" must keep it in Ada-level variables/components. > > I don't quite know what to call your "events" / "asynchronous tasks", > but perhaps the term "work item", which you use in a comment, is better. "Event" looks like a plain event (as opposed to a pulse event). "Asynchronous task" looks like a subprogram, not a task proper, not even a co-routine. My take on this problematic is that there cannot exist a solution implemented at the library level. All these frameworks maybe fun (for the developer) but useless (horror for the end user) when the key problem is not solved. That is, the control-flow state (as you said) and the stack of the local objects both preserved between scheduling points. This can be done IMO only at the language level as co-routines, non-preemptive, cooperative, user-scheduled tasks, call it as you wish. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de