<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 9:07 AM David Cheney <<a href="mailto:david.cheney@canonical.com">david.cheney@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="http://0pointer.de/blog/projects/locking.html" rel="noreferrer" target="_blank">http://0pointer.de/blog/projects/locking.html</a><br>
<br>
In short, opening the same file twice and asserting a lock on it will succeed.<br></blockquote><div><br></div><div>Thanks. The article is a bit exasperated. Yes, there are problems to be aware of, but it doesn't make them unusable in all cases.</div><div> - Juju agents don't get installed onto NFS file systems, so doesn't matter for the agents.</div><div> - We're in full control of the files we're locking, we're not locking some file like /etc/passwd where some other random bit of code in the process is going to open/close it and release the lock by accident.</div><div> - We don't need byte-range locking.</div><div> </div><div>So only the original uncertainty remains: do we care about clients running their home directory on an NFS share, where the NFS *server* is too old to support flock?</div><div><br></div><div>Maybe a named mutex on Windows and a domain socket on *NIX is the way to go. I'm not dead set on flock; I just want something that is simple, robust and portable.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></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 12:04 PM, Andrew Wilkins<br>
<<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>> wrote:<br>
> On Tue, Dec 1, 2015 at 8:57 AM David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>><br>
> wrote:<br>
>><br>
>> fcntl won't work in threaded go applications, it barely works in non<br>
>> threaded applications.<br>
><br>
><br>
> This is news to me. I've used it plenty in the past, in multi-threaded<br>
> programs. Please point me at relevant literature that explains where it<br>
> doesn't work.<br>
><br>
>><br>
>> I'm not interested in "doesn't work on windows" arguments. Yes, we<br>
>> have to support windows, but that doesn't mean we have to be dragged<br>
>> down to it's lowest common denominator.<br>
><br>
><br>
> Agreed, if we're actually crippling anything.<br>
><br>
>><br>
>> I think it's fine to develop a lock type that does the best available<br>
>> for each platform using conditional compilation.<br>
><br>
><br>
> Again, agreed, but only if there's something to be gained by doing this. I'm<br>
> still not convinced there is.<br>
><br>
>> On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins<br>
>> <<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>> wrote:<br>
>> > On Tue, Dec 1, 2015 at 8:03 AM David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins<br>
>> >> <<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>> wrote:<br>
>> >> > On Tue, Dec 1, 2015 at 7:57 AM David Cheney<br>
>> >> > <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Doesn't look like there is windows support, and it uses fcntl<br>
>> >> >> (flock)<br>
>> >> >> under the hood, which is what we have now.<br>
>> >> ><br>
>> >> ><br>
>> >> > flock isn't the problematic thing Tim is talking about. utils/fslock<br>
>> >> > attempts to create a directory in a known location, and if it<br>
>> >> > succeeds,<br>
>> >> > it<br>
>> >> > "holds the lock". Unlocking means removing the directory.<br>
>> >><br>
>> >> The problem is if the process dies/exits/goes mental while holding the<br>
>> >> lock we get into this existential gridlock where we're not sure if the<br>
>> >> process _is_ alive, so we shouldn't remove the lock, or the process is<br>
>> >> dead, so we should remove the lock.<br>
>> >><br>
>> >> abstract unix domain sockets do not have this problem on windows; kill<br>
>> >> the process, file is removed from the abstract namespace.<br>
>> ><br>
>> ><br>
>> > POSIX advisory file locks (flock) do not have this problem either. See:<br>
>> > man(2) fcntl, section "Advisory record locking". When the file<br>
>> > descriptor is<br>
>> > closed, the lock is released; file descriptors are closed when the<br>
>> > process<br>
>> > dies.<br>
>> ><br>
>> > We could build a mutex on top of a unix domain socket, but then we'll<br>
>> > have<br>
>> > something completely separate for Windows. Shared named mutex? I'm not<br>
>> > convinced the overall solution would be any more robust, and I'm pretty<br>
>> > sure<br>
>> > it's going to be more complicated. Happy to be proven wrong though.<br>
>> ><br>
>> >> ><br>
>> >> > We would have to contribute Windows support, but it's not hard, I've<br>
>> >> > done it<br>
>> >> > before.<br>
>> >> ><br>
>> >> >><br>
>> >> >> On Tue, Dec 1, 2015 at 10:55 AM, Casey Marshall<br>
>> >> >> <<a href="mailto:casey.marshall@canonical.com" target="_blank">casey.marshall@canonical.com</a>> wrote:<br>
>> >> >> > How about <a href="http://github.com/camlistore/lock" rel="noreferrer" target="_blank">github.com/camlistore/lock</a> ?<br>
>> >> >> ><br>
>> >> >> > On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey<br>
>> >> >> > <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>><br>
>> >> >> > wrote:<br>
>> >> >> >><br>
>> >> >> >> Hi folks,<br>
>> >> >> >><br>
>> >> >> >> The fslock was a mistake that I added to the codebase some time<br>
>> >> >> >> back.<br>
>> >> >> >> It<br>
>> >> >> >> provided an overly simplistic solution to a more complex problem.<br>
>> >> >> >><br>
>> >> >> >> Really the filesystem shouldn't be used as a locking mechanism.<br>
>> >> >> >><br>
>> >> >> >> Most of the code that exists for the fslock now is working around<br>
>> >> >> >> its<br>
>> >> >> >> deficiencies. Instead we should be looking for a better<br>
>> >> >> >> replacement.<br>
>> >> >> >><br>
>> >> >> >> Some "features" that were added to fslock were added to work<br>
>> >> >> >> around<br>
>> >> >> >> the<br>
>> >> >> >> issue that the lock did not die with the process that created it,<br>
>> >> >> >> so<br>
>> >> >> >> some mechanism was needed to determine whether the lock should be<br>
>> >> >> >> broken<br>
>> >> >> >> or not.<br>
>> >> >> >><br>
>> >> >> >> What we really need is a good OS agnostic abstraction that<br>
>> >> >> >> provides<br>
>> >> >> >> the<br>
>> >> >> >> ability to create a "named" lock, acquire the lock, release the<br>
>> >> >> >> lock,<br>
>> >> >> >> and make sure that the lock dies when the process dies, so<br>
>> >> >> >> another<br>
>> >> >> >> process that is waiting can acquire the lock. This way no<br>
>> >> >> >> "BreakLock"<br>
>> >> >> >> functionality is required, nor do we need to try and do think<br>
>> >> >> >> like<br>
>> >> >> >> remember which process owns the lock.<br>
>> >> >> >><br>
>> >> >> >> So...<br>
>> >> >> >><br>
>> >> >> >> We have three current operating systems we need to support:<br>
>> >> >> >><br>
>> >> >> >> Linux - Ubuntu and CentOS<br>
>> >> >> >> MacOS - client only - bit the CLI uses a lock for the local cache<br>
>> >> >> >> Windows<br>
>> >> >> >><br>
>> >> >> >> For Linux, and possibly MacOS, flock is a possibility, but can we<br>
>> >> >> >> do<br>
>> >> >> >> better? Is there something that is better suited?<br>
>> >> >> >><br>
>> >> >> >> For Windows, while you can create global semaphores or mutex<br>
>> >> >> >> instances,<br>
>> >> >> >> I'm not sure of entities that die with the process. Can people<br>
>> >> >> >> recommend<br>
>> >> >> >> solutions?<br>
>> >> >> >><br>
>> >> >> >> Cheers,<br>
>> >> >> >> Tim<br>
>> >> >> >><br>
>> >> >> >> --<br>
>> >> >> >> Juju-dev mailing list<br>
>> >> >> >> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
>> >> >> >> Modify settings or unsubscribe at:<br>
>> >> >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > --<br>
>> >> >> > Juju-dev mailing list<br>
>> >> >> > <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
>> >> >> > Modify settings or unsubscribe at:<br>
>> >> >> > <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
>> >> >> ><br>
>> >> >><br>
>> >> >> --<br>
>> >> >> Juju-dev mailing list<br>
>> >> >> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
>> >> >> Modify settings or unsubscribe at:<br>
>> >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div>