|
I avoid where I can, and I think the arguments for and against it are quite complicated.
Firstly, don't lock the GUI thread. Fair enough, this is bad for the user but when it is not locked nasty things could happen like making operations that are 'logically synchronous' re-entrant. You can deal with this, but its going to make things harder.
When not on the GUI thread, then I guess the advantage is that continuations can happen on different threads meaning you don't have a blocked thread wasting resources, and could possibly get the benefit of I/O completion. But is this really a problem?
Golden rule for me, keep it simple. Async methods may have their place but as a general paradigm shift I think you trade simplicity for not very much at all.
Regards,
Rob Philpott.
|
|
|
|
|
I'd use it when it would make sense.
Microsoft's attitude about it is ridiculous though.
What was it? Everything that takes longer than 0.2 seconds should be async?
We implemented something like that before async, except we needed about three seconds to load the screen.
Everything was responsive, no way the user had to stare at a loading screen for three seconds... But still they did!
Our users needed to do their job and had to wait for the job to finish, whether that took three seconds or 0.2 seconds and whether the screen froze up or was responsive, they were going to wait.
So there goes all the hard work of making it async, the users would've been just as happy if the screen froze up as they were going to wait anyway...
|
|
|
|
|
Completely agree with all that, but I think it is aimed at making sure tablets have a fluid interface - they want to sell them after all and certain competitors are quite good in this aspect.
WindowsRT from what I recall only had async methods to load files etc. with all the synchronous ones removed and that annoyed me profoundly for about 4 days.
Regards,
Rob Philpott.
|
|
|
|
|
The async API would be OK if it wasn't that complicated. For instance, to open a file async you need to take 4-5 async steps. Really? Why? Why not a simple OpenFileAsync that returns when the file is ready?
|
|
|
|
|
I use async and background processing simply to keep the UI from freezing. If you let the UI freeze for too long your application then starts getting in the way of smooth user interactions with the system as a whole.
|
|
|
|
|
...is awaiting an async operation when the program stops. For example, if you have a TcpListener and do:
var socket = listener.AcceptSocketAsync();
and then later, when your program is shutting down, you call:
listener.Stop();
That first accept socket call will throw an ObjectDisposedException. I generally use a ManualResetEvent for signaling threads to stop, so it's unfortunate that there's no way to do something similar for a lot of the built-in async API.
I hate having catch(ObjectDisposedExceptions) in my code just to handle this case. Otherwise, async/await is a definite time-saver over the previous pattern of BeginXxx/EndXxx calls.
|
|
|
|
|
It's just clean and simple and easy to read/follow the code when only needing a single thread.
I have used async though when the situation called for it.
|
|
|
|
|
I find it surprising that even little things benefit from this rule-of-thumb. So yes, I use the new async.
|
|
|
|
|
I'm using Python asyncio with aiohttp
Pete
|
|
|
|
|
Peter Mulholland wrote: Python asyncio with aiohttp
I'm so glad that someone else also speaks Denebulan here!
Thoihoi Snagglepuss ad furfulim!
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
No need to wrap them in needless nonsense.
|
|
|
|
|
We don't use 4.5 in most places; so I just use threads which have been supported for a longer time
|
|
|
|
|
The only .net I've done since await came out has been low impact maintenance; with no scope for major changes. There're parts of the codebase I'd love to slice off the main thread if/when sufficient funding to do so becomes available. Until then I can't make any major changes.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
After working with it a lot, I've discovered that the whole async/await/Task business is usually not what I want. Task, being tied to the ThreadPool, is useless for long running tasks, especially if you have many of them. The exception handling is a PITA and you really need to study how to handle exceptions very carefully. Having to decorate methods as async, which then enforces (or warns) about certain behaviors, causes no end of grief and confusion as the tendency is to percolate async all the way back up to Main, but wait, you can't decorate Main as async to implement an await.
Last but not least are the mental convolutions one has to go through to figure out what the continuation does. Let's see. When I call await, it returns to the caller so that the caller continues chunking along. When the await completes, it continues with the code after the await and doesn't return to the caller. Now go through that same mental hoop, but with two or more nested awaits.
Except for very limited and understood behaviors, I'll stick with good ol' threads and my own thread pool management, thank you very much.
Marc
|
|
|
|
|
Well said - everything I was thinking.
|
|
|
|
|
I concur.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
or up, if you prefer. 
I like to write async code, although it's kind of "contagious". A piece of async code and all your code tends to become asynchronous.
You have just been Sharapova'd.
|
|
|
|
|
Agent__007 wrote: A piece of async code and all your code tends to become asynchronous.
|
|
|
|
|
C# is not only a language for .NET framework itself, it is a broad language that is now being used for ASP.NET and more specifically, Windows Runtime. If the survey is about .NET framework, then my answer is , "Yes, I prefer using asynchronous programming model". Otherwise, in other cases such as Windows Runtime, you do not have any other option because almost every single object (that may cause a delay in processing; such as resource processing for files or network) has async function type and returns a IAsyncAction. In that case using async is a must otherwise you will fall into the pit of, desperation, I'd say. 
In those cases, async is a good use. Plus, it also saves you from asking questions like, "My WPF app is stuck when I click 'download', please help me". 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Whenever it makes sense should be the correct answer to all these kind of questions.
Sadly it's not and a lot of developers/tech leads, architects amuse themselves complicating the obvious or neglecting the future of an implementation.
Choosing the right tool for the job requires more than knowledge, requires experience, and only experience and technical knowledge combined can properly identify "what makes sense".
|
|
|
|
|
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
|
|
|
|
|
for some simple UI .NET makes some sense - but else it gets nasty 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I say the very same of VB6 (that's what we use for UIs, C/C++/Assembler for the logic)...
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
|
|
|
|
|
The options excludes me from the survey.
We use .NET but I don't.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
modified 28-Sep-15 8:52am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
