Please no. The better way is to use an abstract unix domain socket to create a mutex.
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
