On Tue, Dec 1, 2015 at 10:43 AM, Tim Penhey <tim.pen...@canonical.com> 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 linux the best alternative I know of for a per process mutex is to use a unix domain socket in the abstract namespace. These are automatically removed when the listening socket is closed, or the process dies, there is no need to cleanup stale pids. For other posix systems a pidfile, or on disk unix domain socket is probably the best we can do. > > 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 > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
