1. 28 Jul, 2016 3 commits
  2. 21 Jul, 2016 9 commits
  3. 20 Jul, 2016 2 commits
  4. 19 Jul, 2016 7 commits
  5. 18 Jul, 2016 7 commits
  6. 17 Jul, 2016 2 commits
  7. 16 Jul, 2016 6 commits
  8. 14 Jul, 2016 2 commits
  9. 09 Jul, 2016 2 commits
    • Jim Fulton's avatar
      Internal refactoring of the commit lock manager · f4bcea77
      Jim Fulton authored
      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.
      f4bcea77
    • Jim Fulton's avatar