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 have $HOME as an NFS partition. (Or we just claim it is unsupported.)
If we can do locking within a single machine, there are lots of solutions that work well and are easy (its true that flock doesn't block multiple threads from grabbing the OS lock, but you can just write your own in-memory mutex for the in-process stuff, and use flock to coordinate between processes), NFS meant that flock didn't always work, but if new-enough instances work, then we can go with it. (IIRC, flock was an option on NFS mounts, so we can't actually guarantee that we'll have something like flock between machines.) Bazaar went with "create a directory, put a file in that directory, and rename the directory into place", because it was the only FS primitive that actually worked across lots of filesystem implementations (renaming an empty dir can just replace the dir on some systems), and there was a bug in some implementations of SFTP where "rename a => b" was turned into "mv a => b/a" if b existed. You can detect the latter by writing a nonce and then reading it back. However, we certainly aren't trying to do the level of "you can access the lock via SFTP, NFS, local path and ...". So we don't have to go as lowest-common-denominator. But we do need to consider if we are supporting multi-machine access. I don't think we need cross-machine support for Agent locking, but it seems likely that we do need it for $HOME handling. John =:-> On Tue, Dec 1, 2015 at 11:23 PM, Nate Finch <nate.fi...@canonical.com> wrote: > 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 <roger.pe...@canonical.com> > wrote: > >> On 1 December 2015 at 16:43, Nate Finch <nate.fi...@canonical.com> 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 Windows is "Use a named mutex". >> >> That's not the question we need to answer here, for the configstore case >> anyway. In that case, we really do want to protect access to a shared data >> store in the filesystem, so the term "fslock" is appropriate I think. >> >> > Dave seems to be saying that the >> > only problem with unix domain sockets is if you try to think about them >> like >> > files... which may be a result of us thinking too much about the >> solution >> > and not the problem. (again, I'm not an expert, you guys can duke out >> what >> > the best solution is) I think using hackery with the filesystem >> locking on >> > Windows is a mistake. >> >> Is there something wrong with using the Windows file-exclusive-open >> semantics to implement a lock associated with a entity in the file system? >> Isn't that what it's for? >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
