[issue1539] Rapid commands cause LockUnavailable exceptions

[Trihedral]

New submission from Trihedral <ben.wile at trihedral.com>:

We've set up an application that runs Mercurial script directly from an 
embedded Python interpreter. Primarily this allows us to run long chains of 
Mercurial commands with very little overhead under Win32 as part of an 
automated process. In doing so, however, we've come across a small issue.

When Mercurial attempts to lock a file it tries only once, and if the attempt 
fails then the entire command for which the lock was a part aborts. Since 
Windows caches many file ops it is possible for a file altered during one pass 
to remain inaccessible into the next pass, at least briefly. The result is 
that each successive operation executed in close succession has a chance of 
stumbling over the last. The problem occurs only very occasionally - in our 
test environment just once every few thousand commands. 

We've implemented a fix for the problem by allowing the while loop in 
lock.trylock to repeat a number of times when the exception caught is not 
EEXIST, inserting a 10ms sleep between each failed attempt. If all of the 
attempts fail (we try 6000 times, ie ~1 minute) only then do we raise the 
exception.

Realistically in the worst case the loop only cycles two or three times.

----------
messages: 8749
nosy: Ben at Trihedral
priority: bug
status: unread
title: Rapid commands cause LockUnavailable exceptions

____________________________________________________
Mercurial issue tracker <mercurial-bugs at selenic.com>
<http://www.selenic.com/mercurial/bts/issue1539>
____________________________________________________