Asp Forum - Re: How do you use flock and clean up lock files?

John Carter

8/14/2006 4:49:00 AM

8 Answers

Bill Kelly

8/14/2006 5:00:00 AM

From: "John Carter" <john.carter@tait.co.nz>
>
> Ps: (What do Windowsy types do instead of "Process.fork"? )

Cry, mostly.

:)

Regards,

Bill

Christopher Brown

8/14/2006 5:06:00 AM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, gotcha. You really don't need strong cross-process synch, but
just proof another of your processes already exists.

It sounds like you are following most of the guidance from APUE. In
which case, on *nixes, why not write a pidfile in /var/run? It's a
fairly standard way to do things.
Write the process id into /var/run/<application>.pid. Any launch of
the daemon should check for the existence of this file first and for
added hygiene, check the actual process id written into it against
what's in the process table (or against /proc/<id> if on Linux). At
the end of the day, it's much like the lockfile version, but gives a
bit more information and some tools will work directly with the
pidfile. On some Linux distros, there are tools that will create it
for you and take the daemon managment out of your hands if you choose.

The Windows process model is quite a bit different, and really favors
creating new threads (I guess not what you want here...) Fork / exec
model isn't directly supported. I guess some toolkits attempt to
fake it though. There's a nifty description of the cygwin
implementation here: http://www.cygwin.com/cygwin-ug-net/highl...

I guess this is drifting off-topic from Ruby, so I'll shut up now.

Peace,
Chris

On 14 Aug 2006, at 6:49 AM, John Carter wrote:

>
> On Mon, 14 Aug 2006, Christopher Brown wrote:
>
>> John are you using flock because it's the easiest & most available
>> way to sync across processes? If you had easier access to one of
>> the other sync primitives, would you be using it (i.e. a mutex)?
>> I'm just wondering what the dominant pattern is, and if we are
>> using it because something better hasn't come along.
>
>
> I'm have a generic Daemon class exactly like Process.fork but
> Daemon.spawn does things like...
>
> * Check, via a lock file, that another copy of itself isn't running
> somewhere.
>
> * Has a method to kill all copies of itself (via fuser)
>
> * Detaches itself from the controlling terminal (making it self a true
> Daemon) so it doesn't die if parent process dies.
>
> * Can wait until the dameon has started, can wait for it to die.
>
> I suspect I could use fcntl and mandatory locking, but I'm not sure
> that
> would help with this problem.
>
> Ps: (What do Windowsy types do instead of "Process.fork"? )
>
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter@tait.co.nz
> New Zealand
>
> Carter's Clarification of Murphy's Law.
>
> "Things only ever go right so that they may go more spectacularly
> wrong later."
>
> From this principle, all of life and physics may be deduced.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4ASnrOGxDZoCCzURAv7mAKDHcRZksMTCJDij3D+CayD41sn1ggCfWgVS
RnT7l0wjPDKKUoBHSAjl+nM=
=u++g
-----END PGP SIGNATURE-----

Francis Cianfrocca

8/14/2006 10:45:00 AM

On 8/14/06, John Carter <john.carter@tait.co.nz> wrote:
> I'm have a generic Daemon class exactly like Process.fork but
> Daemon.spawn does things like...
>
> * Check, via a lock file, that another copy of itself isn't running
> somewhere.
>
> * Has a method to kill all copies of itself (via fuser)
>
> * Detaches itself from the controlling terminal (making it self a true
> Daemon) so it doesn't die if parent process dies.
>
> * Can wait until the dameon has started, can wait for it to die.
>
> I suspect I could use fcntl and mandatory locking, but I'm not sure that
> would help with this problem.
>
> Ps: (What do Windowsy types do instead of "Process.fork"? )

I have to say that in my opinion, none of the problems you're trying
to solve are particularly deep nor particularly new. Stick with the
tried and true rather than inventing new practice. On Unix, just use
flock in the standard way. Don't worry about lockfile clutter- that's
what /tmp and /var/run are for. Advisory locks vanish with file
descriptors which makes them graceful when things go wrong. Like any
"mutex" object, hold them for the shortest possible period of time and
make sure you're not susceptible to hanging while you hold one-
otherwise you will go mad once you are in production.

Don't use anything that involves scanning /proc: that locks you not
only to specific Unixes but even to specific versions. Don't use
mandatory locks: this isn't what they were designed for and they are
extremely painful when things go wrong.

On Windows, don't cry, just use CreateProcess. Windows has a strong
cross-process mutex, unlike Linux, so use it. It's heavyweight, but so
what? Nothing is heavier than a process, which is what you're trying
to sync in the first place.

khaines

8/14/2006 1:32:00 PM

Gary Wright

8/14/2006 4:19:00 PM

On Aug 14, 2006, at 6:44 AM, Francis Cianfrocca wrote:
> It's heavyweight, but so what? Nothing is heavier than a process,
> which is what you're trying to sync in the first place.

Hmm. One of the hallmarks of the Unix philosophy was/is the idea that
processes are 'cheap'.

I tend to think that people gravitate towards a threading solution a
little
too reflexively these days and then get bitten by all sorts of
concurrency
issues that can often be avoided via cooperating processes.

The Plan 9 papers offer some interesting insight into the process/thread
dichotomy.

Gary Wright

Francis Cianfrocca

8/14/2006 4:45:00 PM

On 8/14/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
> On Aug 14, 2006, at 6:44 AM, Francis Cianfrocca wrote:
> > It's heavyweight, but so what? Nothing is heavier than a process,
> > which is what you're trying to sync in the first place.
>
> Hmm. One of the hallmarks of the Unix philosophy was/is the idea that
> processes are 'cheap'.
>
> I tend to think that people gravitate towards a threading solution a
> little
> too reflexively these days and then get bitten by all sorts of
> concurrency
> issues that can often be avoided via cooperating processes.
>
> The Plan 9 papers offer some interesting insight into the process/thread
> dichotomy.
>
>
> Gary Wright
>
>
>
>
>

Hmm, you were responding to me so I thought I should clarify. One of
the questions upthread was about Windows, not Plan 9. On Unix just use
flock for process sync. On Windows there is a useable cross-process
mutex.

As far as threads are concerned, I bow to no one in my disdain for
them. (But I've been programming threaded apps since Win32 was in
beta, so I think I'm qualified to disdain them.)

Gary Wright

8/14/2006 5:26:00 PM

On Aug 14, 2006, at 12:45 PM, Francis Cianfrocca wrote:

> Hmm, you were responding to me so I thought I should clarify. One of
> the questions upthread was about Windows, not Plan 9. On Unix just use
> flock for process sync. On Windows there is a useable cross-process
> mutex.
>

I guess it wasn't clear to me that you were responding to
the situation with respect to windows. It seemed like a more general
comment.

Lots of people seem to think Unix threads are heavyweight also.

Gary Wright

M. Edward (Ed) Borasky

8/15/2006 4:04:00 AM

Francis Cianfrocca wrote:
> Depends on the Unix. Solaris threads (not LWPs) are light as a feather.
> Linux 2.6 threads are almost as heavy as processes. Linux 2.4 threads are
> almost unusable.
Almost unusable? How are they worse than "almost as heavy as processes?"

:)

comp.lang.ruby

Re: How do you use flock and clean up lock files?

John Carter

Bill Kelly

Christopher Brown

Francis Cianfrocca

khaines

Gary Wright

Francis Cianfrocca

Gary Wright

M. Edward (Ed) Borasky

x Login to ForumsZone