utils/fslock needs to DIAF

[David Cheney]

s/on windows/on linux (obviously)

On Tue, Dec 1, 2015 at 11:03 AM, David Cheney
<david.cheney at canonical.com> wrote:
> On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins
> <andrew.wilkins at canonical.com> wrote:
>> On Tue, Dec 1, 2015 at 7:57 AM David Cheney <david.cheney at canonical.com>
>> 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
>>> <casey.marshall at canonical.com> wrote:
>>> > How about github.com/camlistore/lock ?
>>> >
>>> > On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey <tim.penhey at 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 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 at lists.ubuntu.com
>>> >> Modify settings or unsubscribe at:
>>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>> >
>>> >
>>> >
>>> > --
>>> > Juju-dev mailing list
>>> > Juju-dev at lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>> >
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev