Bazaar dirstate locking (was: lock_* API change)

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen at xemacs.org>
> Cc: robertc at robertcollins.net,
>     bazaar at lists.canonical.com,
>     monnier at iro.umontreal.ca
> Date: Mon, 17 May 2010 13:10:05 +0900
> 
> Eli Zaretskii writes:
> 
>  > Doing the commit from Emacs is even worse: it locks up _Emacs_ for the
>  > entire commit, which for me takes 4 to 5 minutes on the average.
> 
> Excuse me?  Surely it is nearly trivial to ask Emacs to run a process
> in the background while capturing stdout/stderr in a buffer, even in a
> Windows environment?

I don't know about "nearly trivial".  I'm not an expert on Emacs's VC
design and implementation.  However, the thread starting here:

  http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00170.html

and specifically this message

  http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00224.html

seem to conclude that doing so is highly non-trivial, for the "commit"
and "update" commands.  (Some other VC commands do run asynchronously
in Emacs.)

Maybe I'm missing something, but from almost unanimous complains of
Emacs developers about the speed, I think that I'm not the only one
suffering here, and not just because I miss some feature that already
exists.

In any case, this is not the place to discuss improvements to Emacs.

And the time it takes to edit the log message is not the main PITA,
anyway: I rarely need several minutes for that.  The main problem is
the lock during all those 5 minutes it takes to commit.  The lock
during the log message editing is, for me, just a symptom of the
overall problem: that locks are held long and hard, and that the next
result of this is a tremendous annoyance for users that don't sit
behind the fastest links (mine is a respectable 3.5Mb).

Note that, at least on MS-Windows, there's an additional misfeature,
whereby even a seemingly read-only operations lock dirstate.  E.g., if
I run two "bzr status" commands simultaneously, one of them will
inevitably fail like this:

  bzr: ERROR: Could not acquire lock "D:/usr/eli/bzr/emacs/quickfixes/.bzr/checkout/dirstate": (32, 'CreateFileW', 'The process cannot access the file because it is being used by another process.')

Does "bzr status" indeed need to write to the database?  If not,
perhaps it shouldn't lock dirstate, or maybe the call to CreateFileW
could use appropriate sharing flags to allow other readers run in
parallel?  The fact that this problem does not happen for me on
GNU/Linux is an indication that there are no inherent limitations
here.