«

Hi,
I have (my son has!) implemented protection against multiple instances
causing havoc by creating a directory. This fails if it exists and thus
in a single instruction one gets both the acquire and the test.

Windows has it's mutex which solves the problem. Is there any better
version for UNIX.

Thanks

Nigel King

On Wed, 29 Sep 2004 18:38:06 +0100, Nigel King <> wrote:
> Hi,
> I have (my son has!) implemented protection against multiple instances
> causing havoc by creating a directory. This fails if it exists and thus
> in a single instruction one gets both the acquire and the test.

I assume you want a program (when started) to exit immediately if another
instance is running, as the same user, on the machine?

> Windows has it's mutex which solves the problem. Is there any better
> version for UNIX.

Ok, so Windows has named mutexes which work across processes.

Unix programs normally don't attempt to "protect" themselves in this way. I
can see no harm in two instances of a program running. I can /definitely/
see situations where two programs modifying the same set of files, resulting
in binary garbage, but if these are different programs your approach doesn't
work.

Best is a design which doesn't need locking. Second best is locking which is
tied to the resources (files) which need to be protected. Leaving it up to
the user to be careful is another popular choice

For reference, have a look at procmail's lockfile(1) and mutt's
mutt_dotlock(1). Both deal with protecting mailbox files.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!

On 2004-09-29, Jorgen Grahn <jgrahn-> wrote:

> Unix programs normally don't attempt to "protect" themselves
> in this way.

Some do, some don't. Many system daemons want to make sure
that only a single instance is running. That's one of the
functions of all the *.pid files in /var/run. It's less common
that user programs try to enforce such a restriction, but it
happens. It's usually done by creating a lock file in the
user's home directory if it's a per-user restriction.

> I can /definitely/ see situations where two programs modifying
> the same set of files, resulting in binary garbage, but if
> these are different programs your approach doesn't work.
>
> Best is a design which doesn't need locking. Second best is
> locking which is tied to the resources (files) which need to
> be protected.

Agreed, but creating a lockfile to make sure only a single
instance of the program is running is the standard third
choice.

> Leaving it up to the user to be careful is another popular
> choice

Yup.

--
Grant Edwards grante Yow! PARDON me, am I
at speaking ENGLISH?
visi.com