You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I stumbled upon your code, and found that I have a very similar way of doing a FireAndForget as you have in this library. Only, I don't have the body of the Task.Run delegate wrapped into another invokation. So like this:
I have the above code running fine in production, but am always looking to "harden" it anyways, so I was just wandering: why do you do that? What is the reason of that extra level of invokation?
Also: about the ConfigureAwait... I see that you don't use that. If my understanding about it is right, applying ConfigureAwait(false) means that the synchronisation context doesn't get captured for continuation, which is good here, as we don't need to continue anywhere anyway.
I read somewhere that in library or framework code (I guess this project falls under that category?), ConfigureAwait (false) should almost always be used, as it's more expensive to capture than not to capture, and if you don't need it anyway...
I could be terribly wrong though, as I'm still in the process of wrapping my brain around this whole async/await stuff... Please enlighten me if that's the case ;-)
The text was updated successfully, but these errors were encountered:
I'm actually not certain anymore just looking at the code, but I believe it was done to get around a limitation with Task.Run's exception handling. I do recall starting with just an async lambda, but encountering issues, however It's possible that it is not necessary. The ConfigureAwait(false) is a nice addition.
If you'd like to experiment with it and discover anything I'd be interested to know, but I believe you have the right idea here.
Hi,
I stumbled upon your code, and found that I have a very similar way of doing a FireAndForget as you have in this library. Only, I don't have the body of the Task.Run delegate wrapped into another invokation. So like this:
I have the above code running fine in production, but am always looking to "harden" it anyways, so I was just wandering: why do you do that? What is the reason of that extra level of invokation?
Also: about the ConfigureAwait... I see that you don't use that. If my understanding about it is right, applying
ConfigureAwait(false)
means that the synchronisation context doesn't get captured for continuation, which is good here, as we don't need to continue anywhere anyway.I read somewhere that in library or framework code (I guess this project falls under that category?),
ConfigureAwait (false)
should almost always be used, as it's more expensive to capture than not to capture, and if you don't need it anyway...I could be terribly wrong though, as I'm still in the process of wrapping my brain around this whole async/await stuff... Please enlighten me if that's the case ;-)
The text was updated successfully, but these errors were encountered: