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 X-Received: by 10.107.198.12 with SMTP id w12mr724926iof.105.1523675897188; Fri, 13 Apr 2018 20:18:17 -0700 (PDT) X-Received: by 2002:a9d:445c:: with SMTP id f28-v6mr96633otj.2.1523675896682; Fri, 13 Apr 2018 20:18:16 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!k65-v6no863605ita.0!news-out.google.com!u64-v6ni1570itb.0!nntp.google.com!e130-v6no849694itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 13 Apr 2018 20:18:16 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada-WinRT bindings - Alpha release From: "Dan'l Miller" Injection-Date: Sat, 14 Apr 2018 03:18:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3410 X-Received-Body-CRC: 3505264030 Xref: reader02.eternal-september.org comp.lang.ada:51491 Date: 2018-04-13T20:18:16-07:00 List-Id: On Friday, April 13, 2018 at 4:05:41 AM UTC-5, alby....@gmail.com wrote: > Please feel free to raise issues/question/recommendations for improvement= s either > via GitHub or on his forum After taking a look at the current Ada-WinRT analogue of C#'s await, I post= ed your second issue, which is really just brainstorming food for thought 1) regarding how C#'s Roslyn compiler actually implements await on WinRT-co= mponent async methods in processor-native machine code or on .NET async met= hods in the CLR and 2) regarding how C++/WinRT proposes 2 different solutions=E2=80=94 2.1) one a Microsoft-esque mixin-interface for taming the callback alternat= ive design (that you mention on Ada-WinRT's README.md) and 2.2 the other a solution based on C++'s emerging co-routine feature. In addition to the 2 you list on the README.md (and in addition to any desi= gns resulting from cross-pollination from the food-for-thought above), woul= dn't there be a 3rd Ada task-based solution as well? Especially one where = the task (as costly-to-spawn kernel thread) is not elaborated/spawned at th= e time of invocation of the async function, but rather where a configurable= -sized task pool is where the-operation-has-now-completed handlers all exec= ute for the plethora of hundreds and hundreds of async functions throughout= the WinRT-component framework. Indeed, perhaps there exist multiple such = pools: one for Category-A async operations, another for Category-B async o= perations, and so forth, whatever the categorization scheme therein would b= e. (As the world marches onward to many-core processors and ccNUMA process= or-confederations, each Category there could be thought of as a processor c= ore, or, in an processor confederation, a whole processor.) Does anyone know of a general-purpose Ada library boilerplate analogue of t= he C# await for async subroutines? (I.e., not a custom-crafted design for = each async invocation) (And i.e., not waiting years for Ada co-routines in= Ada2020, if ever) E.g., analogous to the mixing-interface implements in the blog posting https://kennykerr.ca/201= 8/03/09/cppwinrt-producing-async-objects