Can you confirm postfixing every method name with "Async" is either

• required by the compiler, or
• a naming standard we should follow because developers expect async methods to end with this keyword?

You should add “Async” as the suffix of every async method name you write.

I am having difficulties understanding why the keywoard "async" is sometimes used and sometimes omitted in method declarations.

Could you help me understand maybe by providing a link?

async is required when there is an await in the method body.

For the rest of the methods, due to SendRequestAsync being the last statement in the method, we could avoid having to await on it and return the Task instead (Task is similar to promise in other languages). By doing so, we can also avoid having to decide whether to add .ConfigureAwait(false) or not. (.ConfigureAwait(false) is always good when no synchronization context is involved, but may cause extra thread switches when synchronization context is needed. See discussion)

While this explanation is dealing with JavaScript, the underlying way async await works is the same. (C# doesn't yet provide generator, so it's not so good to explain in C#). Languages with async await includes F#, C#, JavaScript and Python. IMO all the rest of the languages are behind time

If we "await" here, is "BulkTrackAsync" really asynchronous?

My apologies if I am missing something.

In .NET, await and async doesn't necessary mean asynchronous :gasp: 😲. One reason to use it is of course to make your code asynchronous, by running several Async methods without awaiting, then subsequently awaiting on the Task.

Here, we only have one SendRequestAsync method, so there's no asynchronous to talk about. However, async is still useful here. SendRequest does a network call, in which traditional synchronous code would have the thread doing nothing, only waiting for the network card to send out the packets, remote server to process, and network card to receive the packets.

SendRequestAsync which calls HttpClient.SendAsync, would instead release the thread to the threadpool (or continue it's event loop if it's the UI thread) at the await. When the packets have been received, the underlying .NET runtime (similar to JVM in Java) would then take a thread from the threadpool and continue the execution, setting our response variable.

The advantage is that the freed up threadpool thread can process other things, instead of consuming memory, handles etc but doing nothing

OR

The freed up UI thread can continue processing events, handling button clicks, process WM_PAINT to prevent "freeze", etc

Could you explain what was the issue you encountered here? Thanks

Deserialize returns null when deserializing string.Empty. The sample code does not check for null when using GetCustomVariablesFromCookie.

Could you explain why the method does not return "void" since nothing is returned? How come it still compiles?

It's the weirdness of the async await syntax. A promise Task is always created and returned. async void is a NO NO, causing the caller not to receive the promise, and thus not able to await on it, thus not able to ensure the order of execution

I took the time to get more familiar with .NET async support.

Method calls in private static void Main(string[] args) have not been renamed, probably because they are commented.

When I uncomment and rename RecordSimplePageView to RecordSimplePageViewAsync in Main(), the compiler warns the keyword await should be used. As soon as the keyword await is added, the compiler warns the Main() method should be async, which is not possible. Is this expected?

Also, if I don't add the await keyword and I shutdown the Piwik server, no exception is reported. Is this expected? How one should handle exceptions?

I've uncommented the methods and made them work using Task.Run().GetAwaiter().GetResult(). Usually doing so is a bad idea due to possible deadlock. However, it is ok for console app, as the Main method doesn't run in the thread pool, thus doesn't need to compete for available threads (if I'm not wrong).