Internal refactoring of the commit lock manager
In working on the next iteration of the lock manager to provide object-level locking, I realized: - It was saner let all waiting try to get locks when locks are released, at least in the more complicated logic to follow. - We really do almost certianly want a multi-threaded server, even if it doesn't run faster (still an open question), because otherwise, big commits will completely block loads. - We don't really want to hold the lock-manager lock while calling the callback. Again, this really only matters if we have a multi-threaded server, but it also feels like a matter of hygiene :) I decided to rework this branch: - Don't hold lock-manager internal lock when calling the callnack. - When releasing the lock, use call_soon_threadsafe to let all waiting have a chance to get the lock. - A little bit of factoring to DRY. (This factoring will be much more useful in the follow-on branch. This rework restores the workability of the thread-per-client model.
Showing
Please register or sign in to comment