SynchronizationContext improperly restored

[OwnageIsMagic]

Ben.BlockingDetector/src/Ben.BlockingDetector/BlockingDetectionMiddleware.cs

Lines 31 to 42 in fce6c53

	var syncCtx = SynchronizationContext.Current;
	SynchronizationContext.SetSynchronizationContext(syncCtx == null ? _detectBlockingSyncCtx : new DetectBlockingSynchronizationContext(_monitor, syncCtx));
	try
	{
	await _next(httpContext);
	}
	finally
	{
	SynchronizationContext.SetSynchronizationContext(syncCtx);
	}

SetSynchronizationContext after awaiting on task restores context on continuation thread (not caller).
See
npgsql/npgsql#1593
https://stackoverflow.com/questions/44418761/cross-thread-exception-after-async-call/44424562#44424562
@benaadams project seems like not maintained, just for your (and others) information.

[maxisam]

I don't know if this is true. I think it is a bit different from the SO link you post.

In that SO post, it clear the SynchronizationContext of the original thread, so after await, it could run on a different thread.

It is like using ConfigureAwait(false), which was exactly what npgsql try to achieve

But here we actually give it a context and create one if there is no context.

so after await, it should go back to the original thread.

[OwnageIsMagic]

@maxisam SynchronizationContext is thread local
And DetectBlockingSynchronizationContext doesn't guarantee await will return to the same thread (it even doesn't override Post/Send methods)

[maxisam]

@OwnageIsMagic I guess I am confused about how await work. I thought await always return to the original context and that is tied with the thread. That is why we don't use configureAwait(false) for UI related code, because it will use any available thread from the thread pool. But if we only use await, it will return to the original thread if there is a context involved.