Re: Preventing Multiple instance of GTK application

[Carlos Pereira <jose carlos pereira ist utl pt>]

Liam R E Quin wrote:
> On Sat, 2008-04-12 at 15:16 +0100, Carlos Pereira wrote:
>
>   
I agree with everything you said.

But in some cases lock files can be useful... this is the way
vim checks if other instances of the same file are open,
so the new instance is open in read-only mode... of course
you need to remove the .filename.swp file yourself, if your machine
crashs... as you said...

I suppose it depends of the specific needs... but in general
I agree with your advices, thank you!

Carlos
> > You can write a .lock file everytime you start and then remove it when 
> > you close. To know if other instance is running, you just have to check 
> > if your .lock file exists.
> >     
>
> Please don't do this.
>
> If you must, take into account
> (1) multiple instances may create the file -- especially if it is
>     on a network file system.  You can use O_CREAT|E_EXCL but it
>     is not guaranteed to work over a network and neither in
>     practice.
>
> (2) after a system crash, or if your application crashes, the lock
>     file will not be removed.
>     A way round this is to make the lock file by a symbolic link
>     to a non-existant file with your process ID in it, and then on
>     startup to check if that process name exists use kill(the_proc, 0),
>     but this will fail on a network drive if the program is running on
>     another machine.
>     A way round this is to include your machine's IP address in the
>     link, but this fails on a laptop (say) that gets a new IP address
>     each time it starts and which might get shut down quickly.
>
> (3) if your application was run as root, or as another user, you might
>     not be able to delete the lock file.
>
> (4) the above 3 items don't have portable solutions between operating
> systems.
>
> It is much better to use dbus, or an X Windows property..
>
> and even better to use a library that packages all this stuff,
> as was suggested by others.
>
> If you do end up making a lock file, consider making it a directory,
> as there are generally fewer locking problems.
>
> best,
>
> Liam
>
>