<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 8:03 AM David Cheney <<a href="mailto:david.cheney@canonical.com">david.cheney@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins <<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>> wrote: > On Tue, Dec 1, 2015 at 7:57 AM David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>> > 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. </blockquote><div> </div><div>POSIX advisory file locks (flock) do not have this problem either. See: man(2) fcntl, section "Advisory record locking". When the file descriptor is closed, the lock is released; file descriptors are closed when the process dies.</div><div> </div><div>We could build a mutex on top of a unix domain socket, but then we'll have something completely separate for Windows. Shared named mutex? I'm not convinced the overall solution would be any more robust, and I'm pretty sure it's going to be more complicated. Happy to be proven wrong though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > 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 >> <<a href="mailto:casey.marshall@canonical.com" target="_blank">casey.marshall@canonical.com</a>> wrote: >> > How about <a href="http://github.com/camlistore/lock" rel="noreferrer" target="_blank">github.com/camlistore/lock</a> ? >> > >> > On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> >> > 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 >> >> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a> >> >> Modify settings or unsubscribe at: >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> >> > >> > >> > >> > -- >> > Juju-dev mailing list >> > <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a> >> > Modify settings or unsubscribe at: >> > <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> >> > >> >> -- >> Juju-dev mailing list >> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a> >> Modify settings or unsubscribe at: >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> </blockquote></div></div>