-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed writing pages in the same thread that does EnqueuePage #2453
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Hey @pictos , regarding unit test for this - I can't think of a good way to create a unit test for this without exposing DiskWriterQueue internals or coming up with additional abstractions that required only for tests. I added an ENSURE check instead, so in case of regression - tests will fail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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