On Tue, Dec 1, 2015 at 7:58 AM David Cheney <[email protected]> wrote:
> Please no. The better way is to use an abstract unix domain socket to > create a mutex. > I don't have a problem with that, but I'd like to know why it's better. > > On Tue, Dec 1, 2015 at 10:56 AM, Andrew Wilkins > <[email protected]> wrote: > > On Tue, Dec 1, 2015 at 7:43 AM 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? > > > > > > I've been wanting to do this for a long time (I think I've whinged in > your > > vicinity about it before), but I've held off because of uncertainty about > > compatibility with NFS (which is probably a rare scenario, and only for > the > > client). > > > > I think it was jam that brought up the heritage of directory locking in > bzr, > > where flock doesn't work reliably over NFS. I think that's old news > though. > > The manpage for flock discusses the NFS/kernel limitations of flock; > since > > we don't go back past precise, we should be fine. > > > > I think flock (fcntl F_SETLK/F_GETLK) is an appropriate option for Linux > and > > OS X. Windows has FileLock > > ( > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202(v=vs.85).aspx > ), > > and LockFileEx (for more control). Just as with F_SETLK, if the process > > dies, the lock is released. > > > > Cheers, > > Andrew > > > >> 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 > > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
