On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
On 10/23/17 17:27, flamencofantasy wrote:
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
On 10/23/17 08:21, Kagamin wrote:
[...]
Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot
language,
with by far the most number of methodologies supported in a
single
language that I've ever encountered.
[...]
There is a lot of misunderstanding about async/await. It has
nothing to
do with "conservation of thread resources" or trading "raw
performance
for an ability
to handle a truly massive number of simultaneous tasks".
Async/await
is just 'syntactic sugar' where the compiler re-writes your
code into
a state machine around APM (Asynchronous programming model
which was
introduced in .NET 2.0 sometime around 2002 I believe).
That's all
there is to it, it makes your asynchronous code look and feel
synchronous.
The only parts of Async/Await that have anything to do with APM
are the interop stubs. C#'s Async/Await is built around the
Task Asynchronous Programming model (e.g. Task and Task<T>) the
compiler lowers to those, not APM. A common misunderstanding is
that Task/Task<T> is based on APM, it's not, Task uses
fundamentally different code underneath. On Linux/macOS it
actually uses libuv (at the end of the day all of these
programming models are callback based).
I’ll throw in my 2 rubbles.
I actually worked on a VM that has async/await feature built-in
(Dart language).
It is a plain syntax sugar for Future/Promise explicit asynchrony
where async automatically return Future[T] or Observable[T] (the
latter is async stream).
Async function with awaits is then re-written as a single
call-back with a basic state machine, each state corresponds to
the line where you did await.
Example:
async double calculateTax(){
double taxRate = await getTaxRates();
double income = await getIncome();
return taxRate * income;
}
Becomes roughly this (a bit more mechanical though):
Future!double calculateTax(){
int state = 0;
Promise!double __ret;
double taxRate;
double income;
void cb() {
if(state == 0) {
state = 1;
getTaxRates().andThen((double ret){
taxRate = ret;
cb();
});
}
else if (state == 1) {
state = 2;
getIncome().andThen((double ret){
income = ret;
cb();
});
else if (state == 2){
__ret.resolve(taxRate*income);
}
}
cb();
}
It doesn’t matter what mechanics you use to complete promises -
be it IO scheduler a-la libuv or something else. Async/await is
agnostic to that.
Still there is a fair amount of machinery to hide the rewrite
from the user and in particular print stack trace as if it was
normal sequential code.
Yes, C#'s async design does make code look and feel
synchronous, and it was intentionally designed that way, but
that is not *why* they did Async. That misunderstanding arises
from an interview that Anders did in which he was asked why
they held Async back for three years after announcing it at
PDC08. In that same talk Anders specifically says that the
purpose of the Async is to free up threads to continue
execution, his example is a Windows Desktop Message Pump and
fetching pictures from the internet (long-wait IO), but the
principal applies to any thread. They held back async for three
years because they needed to refine the language syntax to
something that people could learn and apply in a reasonable
amount of time. IIRC there is a Channel9 video where Anders
explains the evolution of Async Await.
In other words - explicit asynchrony where a thread immediately
returns with Future[T] and moves on to the next task. It’s just
hidden by Async/Await.
