From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-10-25T10:20:31+09:00
Subject: Re: File#flock as a cross-process mutex

------=_Part_11587_11069192.1161739228841
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 Haines
>
> 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).

------=_Part_11587_11069192.1161739228841--