s/on windows/on linux (obviously) On Tue, Dec 1, 2015 at 11:03 AM, David Cheney <[email protected]> wrote: > 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
