Re: utils/fslock needs to DIAF

Note that the NFS case means that we may be wanting to lock a file we are about to write *across machines*. We can decide we won't support that case, but if the point is that we don't want 2 processes concurrently writing to ~./juju/server-cache.yaml, then we need something that works when people

Re: utils/fslock needs to DIAF

On 1 December 2015 at 16:43, Nate Finch wrote: > I think half the problem is that someone named the package fslock and not > oslock, so we're stuck asking the wrong question. > > If the question is "How do I acquire an OS-level lock for a process?" The > answer on

Re: utils/fslock needs to DIAF

Certainly using Windows' file system lock is appropriate for locking its files. I thought the case we were talking about was just abusing that ability as a generic cross-process lock. I wasn't aware of how configstore was using fslock. On Tue, Dec 1, 2015 at 11:58 AM roger peppe

Re: utils/fslock needs to DIAF

So I'm with axw on this one - flock seems like it is a reasonable tool for the job here. FWIW a Unix domain socket also suffers from the "won't work across NFS" problem. Abstract unix domain sockets also have the problem that they won't work with long file paths (what were they thinking?) We have

Re: utils/fslock needs to DIAF

Fully agree that fslock is terrible, but strongly against spending significant engineering effort on it: AFAIAA, core won't need it any more when we've integrated the agents, and that work is progressing nicely. Given that, do we *really* need the os-agnostic abstraction we're discussing? Cheers

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 8:10 PM, roger peppe wrote: > So I'm with axw on this one - flock seems like it is a reasonable tool for > the job here. FWIW a Unix domain socket also suffers from the "won't > work across NFS" problem. Abstract unix domain sockets also > have

Re: utils/fslock needs to DIAF

On 1 December 2015 at 12:34, David Cheney wrote: > On Tue, Dec 1, 2015 at 8:10 PM, roger peppe wrote: >> So I'm with axw on this one - flock seems like it is a reasonable tool for >> the job here. FWIW a Unix domain socket also suffers from

Re: utils/fslock needs to DIAF

I think half the problem is that someone named the package fslock and not oslock, so we're stuck asking the wrong question. If the question is "How do I acquire an OS-level lock for a process?" The answer on Windows is "Use a named mutex". Dave seems to be saying that the only problem with unix

Re: utils/fslock needs to DIAF

fcntl won't work in threaded go applications, it barely works in non threaded applications. I'm not interested in "doesn't work on windows" arguments. Yes, we have to support windows, but that doesn't mean we have to be dragged down to it's lowest common denominator. I think it's fine to develop

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 9:07 AM David Cheney wrote: > http://0pointer.de/blog/projects/locking.html > > In short, opening the same file twice and asserting a lock on it will > succeed. > Thanks. The article is a bit exasperated. Yes, there are problems to be aware of,

Re: utils/fslock needs to DIAF

Doesn't look like there is windows support, and it uses fcntl (flock) under the hood, which is what we have now. On Tue, Dec 1, 2015 at 10:55 AM, Casey Marshall wrote: > How about github.com/camlistore/lock ? > > On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 10:43 AM, Tim Penhey 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

Re: utils/fslock needs to DIAF

Please no. The better way is to use an abstract unix domain socket to create a mutex. On Tue, Dec 1, 2015 at 10:56 AM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 7:43 AM Tim Penhey wrote: >> >> Hi folks, >> >> The fslock was a mistake

utils/fslock needs to DIAF

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

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 7:43 AM Tim Penhey 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

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 7:57 AM David Cheney 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

Re: utils/fslock needs to DIAF

How about github.com/camlistore/lock ? On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey 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

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 7:58 AM David Cheney wrote: > Please no. The better way is to use an abstract unix domain socket to > create a mutex. > I don't have a problem with that, but I'd like to know why it's better. > > On Tue, Dec 1, 2015 at 10:56 AM, Andrew

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 7:57 AM David Cheney > wrote: >> >> Doesn't look like there is windows support, and it uses fcntl (flock) >> under the hood, which is what we have now. > > >

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 8:03 AM David Cheney wrote: > On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins > wrote: > > On Tue, Dec 1, 2015 at 7:57 AM David Cheney > > wrote: > >> > >> Doesn't look like there is

Re: utils/fslock needs to DIAF

http://0pointer.de/blog/projects/locking.html In short, opening the same file twice and asserting a lock on it will succeed. On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 8:57 AM David Cheney > wrote: