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.46.1.38 with SMTP id 38mr2038779ljb.3.1466236562881; Sat, 18 Jun 2016 00:56:02 -0700 (PDT) X-Received: by 10.157.47.177 with SMTP id r46mr203136otb.15.1466236562785; Sat, 18 Jun 2016 00:56:02 -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!w10no1867607lbo.0!news-out.google.com!f5ni1308lbb.0!nntp.google.com!w10no1867603lbo.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 18 Jun 2016 00:56:02 -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 07:56:02 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30772 Date: 2016-06-18T00:56:02-07:00 List-Id: Le vendredi 17 juin 2016 18:18:25 UTC+2, Niklas Holsti a =C3=A9crit=C2=A0: > I had a quick first look, and it seems interesting, but I have two=20 > suggestions to make the development more understandable to the=20 > Ada-oriented reader: >=20 > - First, please do not redefine the word "task", even in the qualified=20 > form "asynchronous task". It is quite confusing, in the Ada context. >=20 > - Second, I question the terminology of "user thread". The "events", or= =20 > "asynchronous tasks", are not "threads" in the sense of keeping their=20 > own machine-level control-flow state; they are automata that are invoked= =20 > from the "executors" through a single "Run" operation. If some=20 > control-flow state must be kept between invocations of "Run", the=20 > "asynchronous task" must keep it in Ada-level variables/components. >=20 > I don't quite know what to call your "events" / "asynchronous tasks",=20 > but perhaps the term "work item", which you use in a comment, is better. Terminology has indeed been much of a pain for me, and something I can impr= ove before freezing the interface. The main issue that I have is to find a = good usability compromise between reusing familiar names when possible, and= avoiding name clashes with existing concepts that have different meanings. I thought I could be fine by focusing on terms that are known to have highl= y overloaded meanings across the software landscape, and thus warn the user= that special attention to definitions is required, but you are right that = in the Ada context "task" is definitely problematic enough to warrant tryin= g to find something else. What's nice about "task", in a C++ context at least, is that the Intel mark= eting department did quite a good job of imposing that as the official term= inology for the elementary work unit of user-mode cooperative multitasking = facilities. They were followed in this by other "task-parallel" libraries l= ike HPX, so these days, when someone familiar with one of these libraries s= ees a "task", they get an idea which is quite close to what I mean here. Common alternatives such as "green threads" or "user thread" are clearly in= ferior, in the sense of being politically loaded in the first case and only= comprehensible by people with an OS tech background in the second case. "c= oroutine" or "process" is abusing established terminology that means someth= ing very different, and "generator" is only really usable for functional ab= stractions that yield results, as it is a very clumsy term to describe proc= edural abstractions that simply return control to the caller. As for "work-item", it is something which I played with recently, but I'm n= ot very keen on it either because in the OpenCL context, it has a totally d= ifferent meaning, and I thus fear that users experienced with the OpenCL te= rminology would interprete a "work-item" as something that is somewhat ligh= tweight, and fall in the trap of too fine a task granularity. Still, it loo= ks better than the options above, so I may converge on it unless a better i= dea emerges. Again, the great thing about "task" is that it is highly descriptive and wa= s not widely used in the C++ community before, but obviously that is not tr= ue in an Ada context. --- On the other hand, I am quite keen on "event" because what I am proposing i= s a near-superset of the OpenCL event model, although the use of a higher-l= evel programming language allows for a much more convenient programming int= erface. An alternative which I had in mind was "completion", but although i= t brings some disambiguation with the interrupt-like event model used by e.= g. GUI toolkits, it is also highly nonstandard, and somewhat confusing in t= he sense that "manipulating a completion" is meaningless.