was thinking about all of this ... one problem with "tasks" in c# is that it mixes the idea of a promise with the execution of code asyncrhonously
I heard a typesafe guy saying the same thing about java futures, so there is probably a performance reason there
if the future value was to be separated in an IPromise<T> for example, I guess async/await wouldn't be so mysterious
@rogeralsing decided to clean up the whole Event namespace.
I assume we have the R# rule for comment all protected/public? it really gets annoying for obvious methods. I have found myself hating myself :)
also there are one or two Obsolete still in Logging, is it safe for me to kill them now?
This message was deleted
I don't like seeing deleted messages :D
I wish they just removed it totally.
it was the secret of the universe, life and everything
I knew it!
@rogeralsing just to get this out of the way, went digging into .net await just to see how it captures the context. as far as I can see, there is no difference between the way LogicalCallContext and SyncrhonizationContext flow between executions, except SyncContext is passed by reference and CallContext is cloned (so there is a little bit overhead there as you noticed), but CallContext always flows while SyncContext is optional. That means you're right in using that, there is no reason to try using a SyncrhonizationContext there.
I found a smell on the actor task scheduler that may account for most problems that are showing, but I'm too tired to investigate today. Boils down to where CallContext is set and restored... I may take a look tomorrow.
@rogeralsing is #907 related only to TestKit? It might be fixed by a custom SynchronizationContext for tests, I think
At least ASP.NET uses SynchronizationContext for the same thing - to keep ThreadStatic ambient context
Yepp, testkit only
However, if i recall correctly, xunit 1.9 has its own synchronizationcontext (?) might be wrong but i think they do