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
h
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
wrote:
> On 1
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 Windows is "Use a named mutex".
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
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 the "won't
>> work across NFS" problem. Abstract unix do
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 the problem that they won't wo
On 1 December 2015 at 10:25, William Reade wrote:
> 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* n
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
W
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
I'm not a linux expert, but definitely a named mutex is exactly the correct
thing to use for Windows. Using something else for this purpose would be
very surprising to a Windows dev and much more likely to be buggy. I don't
see any reason we need to use the exact same implementation on all OSes i
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, but it doesn't make them unu
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:
>>
>> fcntl won't work in threaded go applications, it barel
On Tue, Dec 1, 2015 at 8:57 AM David Cheney
wrote:
> fcntl won't work in threaded go applications, it barely works in non
> threaded applications.
>
This is news to me. I've used it plenty in the past, in multi-threaded
programs. Please point me at relevant literature that explains where it
does
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
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 windows support, and it uses fcntl (flock)
> >> under the hood, which is what we have now
s/on windows/on linux (obviously)
On Tue, Dec 1, 2015 at 11: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 windows support, and it uses fcntl (flock)
>>> under the
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.
>
>
> flock isn't the problematic thing Tim is talking about. uti
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 Wilkins
> wrote:
> > On Tue, Dec 1
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 directory in a known location, and i
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 that I added to the codebase some time back. It
>> provid
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
> wrote:
>>
>> Hi folks,
>>
>> The fslo
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 mechanism.
>
> Most of the code th
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 filesystem shouldn't be used as a
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 mechanism.
>
> Most of the code t
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.
25 matches
Mail list logo