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?
On Wed, 25 Oct 2006, Francis C. 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?
-a
On 10/24/06, [email protected] [email protected] wrote:
On Wed, 25 Oct 2006, Francis C. 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.
On 10/24/06, [email protected] [email protected] wrote:
every
re-acquire, but I’m not looking for condition variables, just mutualhttp://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/doc/rlock.help
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 Wed, 25 Oct 2006, Francis C. wrote:
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
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 C. 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.
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 [email protected] 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 H.
On Wed, 25 Oct 2006 [email protected] wrote:
integrating it into your current codebase, in a less ugly fashion?
That would render your lockfile.rb very cross-platform capable.
Kirk H.
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 10/24/06, [email protected] [email protected] wrote:
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.
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).