Fixed writing pages in the same thread that does EnqueuePage #2453
Conversation
|
I am concerned about the extra dependency Also, do you happen to have a Benchmark (result+code) at hand? |
|
Hi @JKamsker , this dependency exists only because of netstandard1.3 target (for some reason thread pool routines are not available out of box in netstandard1.3). I don't think it is a vulnerable package or something. Benchmark code is contained in this bug - #2451 , as well as results in terms of time taken to run the app. This pr aimed to partially fix it as well |
There was a problem hiding this comment.
Hey @alexbereznikov, thanks for this fix. I've a couple of suggestions.
And please, can you add unit tests for this, that way we can avoid regressions
| { | ||
| public static async Task<bool> WaitAsync(this WaitHandle handle) | ||
| { | ||
| var tcs = new TaskCompletionSource<bool>(); |
There was a problem hiding this comment.
| var tcs = new TaskCompletionSource<bool>(); | |
| var tcs = new TaskCompletionSource<bool>(TaskCreationOptions.RunContinuationsAsynchronously); |
| } | ||
| } | ||
|
|
||
| private sealed class ThreadPoolRegistration : IDisposable |
There was a problem hiding this comment.
If we change this to be a struct does the code work as expected? If so, let's change it and implement the interface implicit, that way we don't need to box it.
Changing this to a struct will avoid allocations if the task is already completed
| private sealed class ThreadPoolRegistration : IDisposable | |
| private readonly struct ThreadPoolRegistration : IDisposable |
| { | ||
| _registeredWaitHandle = ThreadPool.RegisterWaitForSingleObject(handle, | ||
| (state, timedOut) => ((TaskCompletionSource<bool>)state).TrySetResult(!timedOut), tcs, | ||
| Timeout.InfiniteTimeSpan, executeOnlyOnce: true); |
There was a problem hiding this comment.
do we want the Timeout to be infinite? I suggest using a large time, for example 1 day. You would be surprise for systems that get deadlocked because of infinite time spans
AsyncManualResetEvent was using TaskCompletionSource which by default runs continuations synchronously. That led to writing pages in the same thread that called EnqueuePage and, as a result, ~4x performance degradation.
Used more correct way to asynchronously wait for wait handle.
This partially fixes #2451