How about github.com/camlistore/lock ? On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey <[email protected]> wrote:
> Hi folks, > > The fslock was a mistake that I added to the codebase some time back. It > provided an overly simplistic solution to a more complex problem. > > Really the filesystem shouldn't be used as a locking mechanism. > > Most of the code that exists for the fslock now is working around its > deficiencies. Instead we should be looking for a better replacement. > > Some "features" that were added to fslock were added to work around the > issue that the lock did not die with the process that created it, so > some mechanism was needed to determine whether the lock should be broken > or not. > > What we really need is a good OS agnostic abstraction that provides the > ability to create a "named" lock, acquire the lock, release the lock, > and make sure that the lock dies when the process dies, so another > process that is waiting can acquire the lock. This way no "BreakLock" > functionality is required, nor do we need to try and do think like > remember which process owns the lock. > > So... > > We have three current operating systems we need to support: > > Linux - Ubuntu and CentOS > MacOS - client only - bit the CLI uses a lock for the local cache > Windows > > For Linux, and possibly MacOS, flock is a possibility, but can we do > better? Is there something that is better suited? > > For Windows, while you can create global semaphores or mutex instances, > I'm not sure of entities that die with the process. Can people recommend > solutions? > > Cheers, > Tim > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
