|
Glad I could help?
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
async/await is, IMO, something to be avoided except for very specific, simple, quick running, one-level deep, things. Besides the fact that you have to be careful of whether you have long running tasks, which the underlying task management doesn't like (I think this is still accurate), nested async/awaits are a brain-f*** -- ok, when the continuation returns here, then it returns here, then it returns here...but what happens when an exception is thrown...
Frankly, In most cases, I much prefer good 'ol System.Threading.Thread.
Marc
|
|
|
|
|
I wouldn't dream of nesting awaited Tasks, except maybe with a year's analysis and planning of continuations, but in this case, now I've done things properly (found an excellent tutorial), a task takes a lot off my hands, and it is only used to keep the UI responsive and able to cancel, the quasi-long-running API call. It's my own API, and dedicated to this one client.
If I get brave enough, I might stretch it and venture into multiple parallel continuations, but all first level only; start and finish. The TPL, even without the magic of await , just just all the System.Threading plumbing for me.
|
|
|
|
|
Marc Clifton wrote: ok, when the continuation returns here, then it returns here, then it returns here...but what happens when an exception is thrown...
async and await make it easier to reason about that sort of code. For the most part, it's basically the same as synchronous code, except it doesn't block the thread waiting for external calls to complete.
A simple example:
Synchronous code:
Ping ping = new Ping();
try
{
PingReply reply = ping.Send(address);
}
catch (PingException)
{
}
EAP code:
Ping ping = new Ping();
PingCompletedEventHandler handler = null;
handler = (sender, e) =>
{
ping.PingCompleted -= handler;
if (e.Error != null)
{
PingException ex = e.Error as PingException;
if (ex == null) throw new TargeInvocationException("Error", e.Error);
}
else
{
PingReply reply = e.Reply;
}
};
ping.PingCompleted += handler;
ping.SendAsync(address);
Continuation passing code:
Ping ping = new Ping();
Task<PingReply> pingTask = ping.SendPingAsync();
Task resultTask = pingTask.ContinueWith(task =>
{
if (task.IsFauled)
{
AggregateException ex = task.Exception;
ex.Handle(error =>
{
PingException pingEx = error as PingException;
if (pingEx == null) return false;
return true;
});
}
else
{
PingReply reply = task.Result;
}
});
Async code:
Ping ping = new Ping();
try
{
PingReply reply = await ping.SendPingAsync(address);
}
catch (PingException)
{
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Wow, wish I could give you multiple 5's for such a complete response!
Yes, async/await does definitely make life easier, until it doesn't.
Marc
|
|
|
|
|
A damned good, ideally detailed example!
You should make an article of this.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Programming question, in the lounge? tut tut...
|
|
|
|
|
I see no question in my post, and it is even marked as a rant.
|
|
|
|
|
Brady Kelly wrote: Mr. Skeet I heard all threads wait for him to finish.
|
|
|
|
|
|
ever tried doing recursion using async methods, like loading a data tree in which each node has only asyc loading methods available (remember RT version of Windows 8.x in the "old days"? dunno how the API is changed now) . The async and await syntax makes it much, much simpler ...
|
|
|
|
|
Wow, no, never got anything that complex. I would imagine with await you'd need a separate AppDomain for the unknown number of threads, and then just kill it off afterwards, rather than bloat and complicate your code tracking them.
|
|
|
|
|
Well, what I meant here is that it's not really that complicated using async/await , compared to other methods. And it can be used consistently in any layers of call stacks ...
Imagine in a system that only asynchronous system calls are available (like in the RT subsystem of Windows and in part of nodejs), it would be very hard to build any backend, midware or API systems complex enough for real world applications, which most likely have many layers of abstraction on top, base on callbacks or event handlers. It's sometimes been referred to as callback hell, the origin of many subtle bugs ...
However async/await support (kind of coroutine) of a language makes it possible to make the code almost like the synchrounous one so that a programer can apply the sequential execution reasonning about the code and does not has to worry about the underlying async mechanism, which are managed by thread pools or even are not thread based (event driven systems, like nodejs). We had built quite complex systems in nodejs (using promises, similar to async/await) and Windows RT (before) using async/await.
|
|
|
|
|
|
Yeah. I miss his answers (@SAKryukov) too.
Where did he go?
|
|
|
|
|
No idea, but account is still active and in 1st place of who is who by rep
OriginalGriff has overflown the counter and has been relegated to the last place due to base 2 complement
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
(going for the 'how low a response can a post get' record) my welder cant run a 3.2 mm stick, that's about 110 amps, for more than 15 mins without the heat cut out kicking in and rendering it dead for half an hour. Its a sodding pain, this pergola is going to take days to put up.
|
|
|
|
|
Munchies_Matt wrote: (going for the 'how low a response can a post get' record) I'm just posting to make you fail. Goes well with your welder
|
|
|
|
|
So now you're in pergolatory?
|
|
|
|
|
Sorry, but that is very good.
|
|
|
|
|
Then why are you sorry?
Funny thing, here in SA, the majority of English speakers use, "Sorry?" to get someone's attention, e.g. "Sorry, would you mind not standing on my toe?". I use it often myself, and have made a firm resolution to only use in in genuinely apologetic contexts, and a normal greeting, like "Howzit, bru" instead, or just "bru".
That translates to, "How are things, brother?"
|
|
|
|
|
Brady Kelly wrote: English speakers use, "Sorry?" to get someone's attention
My wife does this mostly because she's hard of hearing and needs me to repeat myself, which I hate doing doing. What I really hate though is the obligatory conversation starters such as 'How are you?/Fine, and you?'. I still prefer the '90s phrase 'wassssup'.
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: What I really hate though is the obligatory conversation starters such as 'How are you?/Fine, and you?'. That's where 'Howzit' is really handy. No reply required, just maybe an echo.
I've long quite salutations on all but the first email I send to person I haven't communicated with before, and when I'm feeling really friendly I'll throw in a "Hi. Then the rest of the topic."
|
|
|
|
|
Brady Kelly wrote: Then why are you sorry?
Its just an Anglicism, and I dont mean men in black dresses.....
|
|
|
|
|
Stupid, obvious question, but wth...have you tried a fan?
"Go forth into the source" - Neal Morse
|
|
|
|