151–160 of 186 posts
So much content and the `ConfigureAwait` portion, which is the BIGGEST gotcha in the whole shebang in my opinion, is not filled out?! Especially for Xamarin, you need to understand and use ConfigureAwait to properly bounce between UI / background threads.
Earlier quoted context omitted.
Database operations should be async, you shouldn't consume them synchronously, as they do IO. Async/Await came out in 2012, almost a decade ago (and with great first party library support, I might add). Moralizing aside, sometimes you do want to call async APIs as synchronous code. I don't think there should be a synchronous version of the API implemented as well, you just need to do var myValue = DoSomethingAsync().…
Some things simply don't have an async API at the low level, e.g. DNS lookup: there is no asynchronous version of getaddrinfo(3). So if you look at the .NET sources, you'll see that Dns.GetHostEntryAsync pushes a task to a thread pool that calls getaddrinfo(3). In the end, you arrive at a "sync top-level APIs -- async library APIs -- sync low-level OS APIs" sandwich of dubious efficiency.
Earlier quoted context omitted.
Some things simply don't have an async API at the low level, e.g. DNS lookup: there is no asynchronous version of getaddrinfo(3). So if you look at the .NET sources, you'll see that Dns.GetHostEntryAsync pushes a task to a thread pool that calls getaddrinfo(3). In the end, you arrive at a "sync top-level APIs -- async library APIs -- sync low-level OS APIs" sandwich of dubious efficiency.
When there's sync OS APIs what's the point of async over threads? I thought async APIs use async or polling version of syscalls and not blocking ones.
Most documentation -- and most code I've seen in the wild -- reads like this:
var foo = await GetFooAsync(...);
var bar = await GetBarAsync(...);
var baz = await GetBazAsync(...);
The following version is more verbose -- which makes it feel slower -- but can provide dramatic speed ups even for a single user by overlapping requests so that they run concurrently:
var fooTask = GetFooAsync(...);
var barTask = GetBarAsync(...);
var bazTask = GetBazAsync(...);
var foo = await fooTask;
var bar = await barTask;
var baz = await bazTask;
I hope the author at some point adds the section on ConfigureAwait. I've seen code bases where the devs have added .ConfigureAwait(false) to all invokations "just to make sure".
Earlier quoted context omitted.
> Consider that the minimum grain of a Task.Delay is 1 millisecond. The minimum here is contingent on a few things. The API can accept a TimeSpan which can express durations as low as 100ns (10M ticks per second: https://docs.microsoft.com/dotnet/api/system.timespan.ticksp... ). The actual delay is subject to the timer frequency, which can be as high as 16ms and depends on the OS configuration (eg, see https://stacko…
> I'd recommend people take the simple approach of using async/await at the application layer and only change that approach if profiling demonstrates that it's becoming a performance bottleneck. Despite some of the things I presented in my original comment, I absolutely agree with this. There are only a few extreme cases where async/await simply can't get the job done. These edge cases are usually explicitly discover…
Why do we need the `async` keyword? What is the difference between a function which returns a Task , and an async function which returns a Task ?
The most common issue I see with async programming is that the naive style seen in most samples/docs is strictly slower than standard imperative programming for one user . In other words, it's pure overhead with no benefit at all unless you're at a very large scale and approaching 100% capacity on your hosts. Most documentation -- and most code I've seen in the wild -- reads like this: var foo = await GetFooAsync(...…
In JS this could be...
const [
fooTask,
barTask,
bazTask,
] = await Promise.all([
GetFooAsync(...),
GetBarAsync(...),
GetBazAsync(...)
]);
The most common issue I see with async programming is that the naive style seen in most samples/docs is strictly slower than standard imperative programming for one user . In other words, it's pure overhead with no benefit at all unless you're at a very large scale and approaching 100% capacity on your hosts. Most documentation -- and most code I've seen in the wild -- reads like this: var foo = await GetFooAsync(...…
Does C# not have an equivalent to JavaScript's Promise.all?? In JS this could be... const [ fooTask, barTask, bazTask, ] = await Promise.all([ GetFooAsync(...), GetBarAsync(...), GetBazAsync(...) ]); ... PS in your code above you assign GetBazAsync to bar and baz. :-)
I believe this kind of copy-paste "last line effect" one of the most common errors in programming: https://hownot2code.com/2016/08/15/the-last-line-effect-typo...
Task.WaitAll is the C# equivalent: https://docs.microsoft.com/en-us/dotnet/api/system.threading...
But it's not necessarily faster, there are corner cases where waiting for all tasks prevents some concurrent computations (e.g.: JSON parsing) from occurring.
The most common issue I see with async programming is that the naive style seen in most samples/docs is strictly slower than standard imperative programming for one user . In other words, it's pure overhead with no benefit at all unless you're at a very large scale and approaching 100% capacity on your hosts. Most documentation -- and most code I've seen in the wild -- reads like this: var foo = await GetFooAsync(...…
Does C# not have an equivalent to JavaScript's Promise.all?? In JS this could be... const [ fooTask, barTask, bazTask, ] = await Promise.all([ GetFooAsync(...), GetBarAsync(...), GetBazAsync(...) ]); ... PS in your code above you assign GetBazAsync to bar and baz. :-)
i.e. you have to write
var (fooTask, barTask, bazTask) = (GetFooAsync(), GetBarAsync(), GetBazAsync());
await Task.WhenAll(fooTask, barTask, bazTask);
var (foo, bar, baz) = (fooTask.Result, barTask.Result, bazTask.Result);
var (foo, bar, baz) = await (GetFooAsync(), GetBarAsync(), GetBazAsync());