How to check if there is one instance of application is already in memory

[Sam_Hendley]

I used the socket method, here is the script I used, if you need help
on figuring out how to integrate it, check out my source
(http://ptc.sourceforge.net goto downloads). If anyone wants to modify
this script so that it makes sure the socket is openned locally, to
protect against remotely activating the program it would be even
better.
Sam

Quoting Cliff Wells <LogiplexSoftware@earthlink.net>:

portlisteners.py (3.35 KB)

···

On Wed, 2003-07-09 at 13:04, Uwe C. Schroeder wrote:
> On Wednesday 09 July 2003 11:11 am, Cliff Wells wrote:
> > On Wed, 2003-07-09 at 02:23, Ruslan Spivak wrote:
> > > Hello.
> > >
> > > How to check if there is one instance of application is already
in
> > > memory. And if so, terminate the loading of anotherr instance.
I need
> > > code both for Windows and Linux.
> >
> > Have the program open a socket on startup. If a second copy of
the
> > program is started it will fail to open this socket. That's the
first
> > step. The problem is that some other unrelated program may have
> > reserved that socket (although this is unlikely in practice).
There are
> > a few strategies you can take at this point, the one I prefer is
to have
> > the instance of the program that is already running listen on
that
> > socket for connections, when the second copy starts, finds out
that it
> > can't open that socket, try to connect to it. If it succeeds,
have it
> > talk to the first instance to verify that it is indeed another
copy of
> > itself. An added benefit of this is that you can use this
technique to
> > pass information to the already running instance. For example,
if the
> > program is run with a filename as an argument, it could pass
this
> > filename onto the already running instance so that the first
instance
> > could open the file.
>
> Your idea certainly has benefits. But wouldn't it be less overkill
to just
> create a lockfile with the process id in it (or something the like)
?
> Lockfiles worked well for unix in the last decade (and still do).

"Well" is always a relative term. There is a small moment in time
between checking if the lockfile exists and creating it where two
instances could think they were the sole instance. This seems
unlikely
but in these days of double-clicking it's fairly easy to start two
processes back-to-back.

> Also using a socket might be a problem depending on platform.
Sockets don't
> simply "go away" once you disconnect. They take their time
depending on the
> parameters in the network layer of the OS.

This is usually a matter of seconds. But yes, you are correct.
I've
only encountered problems like this when an application crashes
without
closing the socket. I've never seen a problem outside of that. But
then, it was still only a short period (maybe 5 seconds? can't
recall)
that the socket was tied up. This is still a bit better than the
lockfile solution where a crashed app often requires manually
removing
the lock before another instance can run (although there are ways
around
this as well, i.e. storing the PID in the lockfile is the usual
way).

> So you might end up with a deadlock, meaning the original copy
might be gone,
> but the socket is still around and can't be bound since it's in a
fin_wait
> state. So if you start/stop/start/stop/start your program it might
not start
> the second time because of the socket still lingering around

But still only for a short period (at least on Linux and Windows NT,
which are the two platforms I've tried this on).

> Personally I'd read the process table and check for "myself"

That's difficult to do in a cross-platform way. Worse, with Python,
*all* instances are called "python", so it can difficult to discern
which is your application. IMHO, this should probably be considered
a
bug.

Ultimately, there isn't really a foolproof way of solving this
problem.
Each solution simply shuffles the same problem (lack of atomicity
for
the test) elsewhere. I prefer the socket method because even in the
case of deadlock, it resolves itself after a short while without
user
intervention.

Regards,

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 (800) 735-0555

---------------------------------------------------------------------
To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwindows.org