Move locking operations onto the module's thread #2866
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
This is a branch to test the performance impact of moving work from blocking threads to the module thread.
In places where we previously spawned a blocking task to acquire a lock, we now use the module's job queue instead. This could slow down performance, since places where we are acquiring shared locks are now running serially. It also probably moves a little extra computation that happens before/after locking.
If this doesn't cause performance problems, we could probably simplify our concurrency significantly with a similar approach. If we do see some performance problems, we will probably need the job queue to have its own scheduling logic to allow queries to happen in parallel.
Expected complexity level and risk
3? This PR shouldn't be merged. Its a PoC we can use for performance testing.
Testing