On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins <[email protected]> wrote: > On Tue, Dec 1, 2015 at 7:57 AM David Cheney <[email protected]> > wrote: >> >> Doesn't look like there is windows support, and it uses fcntl (flock) >> under the hood, which is what we have now. > > > flock isn't the problematic thing Tim is talking about. utils/fslock > attempts to create a directory in a known location, and if it succeeds, it > "holds the lock". Unlocking means removing the directory.
The problem is if the process dies/exits/goes mental while holding the lock we get into this existential gridlock where we're not sure if the process _is_ alive, so we shouldn't remove the lock, or the process is dead, so we should remove the lock. abstract unix domain sockets do not have this problem on windows; kill the process, file is removed from the abstract namespace. > > We would have to contribute Windows support, but it's not hard, I've done it > before. > >> >> On Tue, Dec 1, 2015 at 10:55 AM, Casey Marshall >> <[email protected]> wrote: >> > 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 >> > >> >> -- >> 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
