Re:Asynchronous Programming in C#
by BoyRobot777 on Friday September 24, 2021 @01:20PM
(#28645307)
You won't need to rewrite into async model, because project Loom will introduce virtual threads. That means your sync code will look exactly the same, but will have scalability of async.
Given that you understand it well -- do you know why the compiler accepts async void in the first place?
Re:Asynchronous Programming in C#
by Matthias247 on Saturday September 25, 2021 @01:23AM
(#28650738)
I think it made sense for UI integrations. From a synchronous OnClick delegate you could start an async void function - which essentially starts a background task that lives even after the click handler returns. Returning a Task here would not have made sense since nothing awaits it. But arguably the use-case could also have been fulfilled by calling `Task.Run` in the handler to spawn a background task.
Without knowing what the underlying method does, the async method may block the UI thread because until the first await which doesn't immediately continue it runs on the UI thread.
Re:Asynchronous Programming in C#
by brewmarche on Saturday September 25, 2021 @07:42AM
(#28652334)
I think it was for backwards compatibility with event handlers (which need to return void)
Avoid "async void" was one of the catchy mnemonics I learned the hard way, because one day our production server crashed because it threw an exception in an async void.
I'm working on Java web services now, and it's written using synchronous Java servlet framework (Spring/Jetty). My hidden fear is that one day we'll discover that our synchronous APIs will have to be completely re-written in the async model.