Has anyone wrapped up File#flock so it can used as a platform-independent
cross-process mutex? (I'm getting tired of writing the same code into every
app I do.) Or does anyone have a better idea?
can you elaborate? do you need to yield the resource and re-aquire it?
-a
···
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
Has anyone wrapped up File#flock so it can used as a platform-independent
cross-process mutex? (I'm getting tired of writing the same code into every
app I do.) Or does anyone have a better idea?
--
my religion is very simple. my religion is kindness. -- the dalai lama
Most of the time I want to make sure only one process is running in a
particular directory at a time. And if another one tries to start up, it
should get an exception. And I also want it to be completely behaved in the
presence of both hangs and crashes. Sometimes I do need to yield and
re-acquire, but I'm not looking for condition variables, just mutual
exclusion.
···
On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
> Has anyone wrapped up File#flock so it can used as a
platform-independent
> cross-process mutex? (I'm getting tired of writing the same code into
every
> app I do.) Or does anyone have a better idea?can you elaborate? do you need to yield the resource and re-aquire it?
you might look at this
http://rubyforge.org/frs/?group_id=1024&release_id=3473
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/README
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/doc/rlock.help
i use it all over the place in production across many nfs mounted node to
ensure only one node runs a particular process. one of the nice features it
has is that it auto-detects stale locks. the basic process works like this:
- once we aquire a lock we start a thread (or process - it's configurable)
to touch the file every so often (configurable)
- if a process hangs or dies the lock becomes stale. this will be noticed
by a process trying to aquire the lock - someone will eventually steal the
lock if it becomes too stale and then timeout for a while because i'm
paranoid like that. this timeout is also configurable.
the whole process is atomic, even on nfs, and of course works on local
filesystems to. you can use via the api like so
lockfile = Lockfile.new 'my.lock'
or run existing programs without modification like so
rlock my.lock --rlock-option -- some_old_program --some_old_program-option
so it's easy to integrate into an existing system.
note that this is file based, not flock based so, while the performance isn't
that of flock, it's not bad either. though i'm guessing from your use case
you are locking too often...
regards.
-a
···
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
> Has anyone wrapped up File#flock so it can used as a
platform-independent
> cross-process mutex? (I'm getting tired of writing the same code into
every
> app I do.) Or does anyone have a better idea?can you elaborate? do you need to yield the resource and re-aquire it?
Most of the time I want to make sure only one process is running in a
particular directory at a time. And if another one tries to start up, it
should get an exception. And I also want it to be completely behaved in the
presence of both hangs and crashes. Sometimes I do need to yield and
re-acquire, but I'm not looking for condition variables, just mutual
exclusion.
--
my religion is very simple. my religion is kindness. -- the dalai lama
Thanks Ara. Some interesting ideas in there. I don't care for the outboard
process or thread, but I'll give this a try.
···
On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
> On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>>
>> On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
>>
>> > Has anyone wrapped up File#flock so it can used as a
>> platform-independent
>> > cross-process mutex? (I'm getting tired of writing the same code into
>> every
>> > app I do.) Or does anyone have a better idea?
>>
>> can you elaborate? do you need to yield the resource and re-aquire it?
>
> Most of the time I want to make sure only one process is running in a
> particular directory at a time. And if another one tries to start up, it
> should get an exception. And I also want it to be completely behaved in
the
> presence of both hangs and crashes. Sometimes I do need to yield and
> re-acquire, but I'm not looking for condition variables, just mutual
> exclusion.you might look at this
http://rubyforge.org/frs/?group_id=1024&release_id=3473
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/README
http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/doc/rlock.help
It works very well, but doesn't work on Windows, though. Ara, if I sent you my hack that provides flock based locking if a) specifically requested or b) the default file based algorithm fails, would you be interested in integrating it into your current codebase, in a less ugly fashion?
That would render your lockfile.rb very cross-platform capable.
Kirk Haines
···
On Wed, 25 Oct 2006 ara.t.howard@noaa.gov wrote:
note that this is file based, not flock based so, while the performance isn't
that of flock, it's not bad either. though i'm guessing from your use case
you are locking too often...
i don't either - but it was learnt in the trenches: process hung on nfs aren't
that responsive so it's safest to have an external process.
fyi.
-a
···
On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
Thanks Ara. Some interesting ideas in there. I don't care for the outboard
process or thread, but I'll give this a try.
--
my religion is very simple. my religion is kindness. -- the dalai lama
i'm interested. remember though that flock will fail if rpc.statd isn't
running is firewalled (common). also, flock locks and fcntl (posix) are
incompatible on many *nixes... it's damn ugly if you ask me. anyhow, it would
be good to have a a cross platform lockfile lib. send me some or code or just
you thoughts.
cheers.
-a
···
On Wed, 25 Oct 2006 khaines@enigo.com wrote:
On Wed, 25 Oct 2006 ara.t.howard@noaa.gov wrote:
note that this is file based, not flock based so, while the performance isn't
that of flock, it's not bad either. though i'm guessing from your use case
you are locking too often...It works very well, but doesn't work on Windows, though. Ara, if I sent you my hack that provides flock based locking if a) specifically requested or b) the default file based algorithm fails, would you be interested in integrating it into your current codebase, in a less ugly fashion?
That would render your lockfile.rb very cross-platform capable.
Kirk Haines
--
my religion is very simple. my religion is kindness. -- the dalai lama
I have to admit, it seems to me that we're dealing with two different
problem domains here. Solving this on NFS introduces so many additional
challenges that it might be nice to have a solution that uses all the
concepts you've worked out, but only needs to work intramachine.
I thought of using the Windows "mutex" object (which actually can work
across processes), and flock on Unix, but that leaves you with a compiled
extension (puke).
···
On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Wed, 25 Oct 2006 khaines@enigo.com wrote:
> On Wed, 25 Oct 2006 ara.t.howard@noaa.gov wrote:
>
>> note that this is file based, not flock based so, while the performance
>> isn't
>> that of flock, it's not bad either. though i'm guessing from your use
case
>> you are locking too often...
>
> It works very well, but doesn't work on Windows, though. Ara, if I sent
you
> my hack that provides flock based locking if a) specifically requested
or b)
> the default file based algorithm fails, would you be interested in
> integrating it into your current codebase, in a less ugly fashion?
>
> That would render your lockfile.rb very cross-platform capable.
>
> Kirk Hainesi'm interested. remember though that flock will fail if rpc.statd isn't
running is firewalled (common). also, flock locks and fcntl (posix) are
incompatible on many *nixes... it's damn ugly if you ask me. anyhow, it
would
be good to have a a cross platform lockfile lib. send me some or code or
just
you thoughts.