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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.25.31.131 with SMTP id f125mr439681lff.2.1466237789278; Sat, 18 Jun 2016 01:16:29 -0700 (PDT) X-Received: by 10.157.41.105 with SMTP id d96mr203583otb.19.1466237789176; Sat, 18 Jun 2016 01:16:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!oe3no3686795lbb.1!news-out.google.com!f5ni1472lbb.0!nntp.google.com!oe3no3686789lbb.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 18 Jun 2016 01:16:28 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=78.192.88.225; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 78.192.88.225 References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: RFC: Prototype for a user threading library in Ada From: Hadrien Grasland Injection-Date: Sat, 18 Jun 2016 08:16:29 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30773 Date: 2016-06-18T01:16:28-07:00 List-Id: Le vendredi 17 juin 2016 18:46:46 UTC+2, Dmitry A. Kazakov a =C3=A9crit=C2= =A0: > On 2016-06-17 18:18, Niklas Holsti wrote: >=20 > > - First, please do not redefine the word "task", even in the qualified > > form "asynchronous task". It is quite confusing, in the Ada context. >=20 > Yes. >=20 > > - 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 invoke= d > > 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= . >=20 > "Event" looks like a plain event (as opposed to a pulse event).=20 > "Asynchronous task" looks like a subprogram, not a task proper, not even= =20 > a co-routine. >=20 > My take on this problematic is that there cannot exist a solution=20 > implemented at the library level. All these frameworks maybe fun (for=20 > the developer) but useless (horror for the end user) when the key=20 > problem is not solved. That is, the control-flow state (as you said) and= =20 > the stack of the local objects both preserved between scheduling points.= =20 > This can be done IMO only at the language level as co-routines,=20 > non-preemptive, cooperative, user-scheduled tasks, call it as you wish. I agree that implementation support for coroutines would be extremely valua= ble, if it were available at the language level (as in Python, C#, Go...) o= r even in specific implementations (as in Visual C++). In addition to the benefits you mention, I will also add that a language-le= vel implementation can potentially trap blocking system calls and substitut= e them with task switches for latency hiding. It will also get wide support= from the standard library instead of requiring many custom primitives an w= rapper, which means more development time to focus on the core concurrency = model. However, I think that as it stands, we are just about as likely to see it h= appening in Ada as we are to get lambdas and first-class function objects. = So at some point, it is necessary to move on, and try to do what we can at = the library level. In my case, state saving is partially available in the s= ense that any data member of Asynchronous_Task is preserved across iteratio= ns, so we do get something relatively straightforward to use, but I will ce= rtainly agree that this something is less flexible and pleasant to use than= full language-level coroutine/generator support. If this prototype works well, there is hope to take it further in the long = term, though. For example, the productive interaction of HPX with the C++17= commitee has shown that having a working (even if clumsy) implementation o= f new concurrent primitives is a very strong argument when interacting with= a language standardization commitee in order to request new language featu= res that make these primitives easier to implement and use. And even if we really cannot get the language features, if I get this proje= ct far enough to motivate other developers to join, it is also possible to = envision implementing architecture- and OS-specific automatic task state sa= ving, as in Intel TBB, which is something which I will refuse to do for now= because it is too difficult to handle for a lone developer with a limited = base of test hardware.