On Wed, Nov 10, 2010 at 1:29 PM, Paul Sladen <email address hidden> wrote:
> AFAICT, there are various levels of "fixing" this required, at the
> simpler end being:
>
> 1. Don't bother querying the lock for read-only operations (just fail on exception in the case of genuinely inconsistent data)
This would break bzr when updates occured.
> 2. For commit, only hold the lock during the actual update phase (after the use was closed the editor and saved the tempfile) (comment #6).
This would break when a reader exists (cannot boot a reader out)
leading to a half-done commit in a very confusing fashion.
> to the far larger end of things:
>
> 3. Changing the fundamental update mechanism/process to be lock-free
> and persistently self-coherent (comment #10).
On Wed, Nov 10, 2010 at 1:29 PM, Paul Sladen <email address hidden> wrote:
> AFAICT, there are various levels of "fixing" this required, at the
> simpler end being:
>
> 1. Don't bother querying the lock for read-only operations (just fail on exception in the case of genuinely inconsistent data)
This would break bzr when updates occured.
> 2. For commit, only hold the lock during the actual update phase (after the use was closed the editor and saved the tempfile) (comment #6).
This would break when a reader exists (cannot boot a reader out)
leading to a half-done commit in a very confusing fashion.
> to the far larger end of things:
>
> 3. Changing the fundamental update mechanism/process to be lock-free
> and persistently self-coherent (comment #10).
Prototype code is written.
-Rob