On 18/02/2017 01:37, Marvin Humphrey wrote:
Lucy's read locking is only needed on NFS, and only to prevent `Stale NFS
filehandle` exceptions.
I thought so, too, but then I realized that BackgroundMerger also protects the
snapshot it's working on with a read lock.
That means Lucy would need at least 3 different locking
implementations:
* `flock` on Linux/BSD/Darwin/most-other-unix
* `CreateFile`/`FileLockEx` on Windows
* The current system (?) on Solaris/SmartOS/etc
Yes, but Windows/UNIX could share the same Lock subclass.
In my career as a software developer, NFS competes with Internet Explorer 6 as
the biggest waster of my time,
;)
Sounds good, if you're willing. :)
Here's my work-in-progress branch on Github:
https://github.com/nwellnhof/lucy/commits/locky-mclockface
I realized that we have to align the Lock class with native lock semantics
first. So I merged SharedLock into LockFileLock, providing Request_Shared and
Request_Exclusive methods (note that Github collapses the crucial
core/Lucy/Store/Lock.c diff):
https://github.com/nwellnhof/lucy/commit/f390bc51cb8964606084287ccc8e9258d7a5e96b
This allows to remove the global deletion lock:
https://github.com/nwellnhof/lucy/commit/42ca7d3002b69134f261b8c555cb99a3cc17cce3
The changes to the merge lock logic are minor (after the initial FilePurger
change):
https://github.com/nwellnhof/lucy/commit/323e4472a629d5fd64e4678d4921ade1d521d1d9
I also found a couple of issues with the existing code, but nothing too serious.
It should be easy to implement native locks on top of these changes. The
hardest part is probably to make sure that all users of an index agree on a
single locking mechanism.
Nick
