RFC: Netx - Implement SingeInstanceService
Omair Majid
omajid at redhat.com
Mon Jun 22 07:22:29 PDT 2009
Hi,
Andrew Haley wrote:
> Omair Majid wrote:
>
>> The attached patch adds support for SingleInstanceService to Netx.
>>
>> It creates a lock file under ~/.netx/locks/ once an application adds a
>> SingleInstanceListener to the SingleInstanceService. A second instance
>> of the application sees this lock file, sends it's arguments to the
>> first instance and shuts down.
>>
>> ChangeLog:
>> 2009-06-18 Omair Majid <omajid at redhat.com>
>>
>> *rt/net/sourceforge/jnlp/Launcher.java
>> (launchApplication): Check for any existing single instance.
>> Dont start a second instance.
>> *rt/net/sourceforge/jnlp/resources/Messages.properties: Add
>> RNoLockDir.
>> *rt/net/sourceforge/jnlp/services/ExtendedSingleInstanceService.java
>> New file.
>> *rt/net/sourceforge/jnlp/services/InstanceExistsException.java: New
>> file.
>> *rt/net/sourceforge/jnlp/services/ServiceUtil.java
>> (getSingleInstanceService): New function.
>> (checkExistingSingleInstance): New function.
>> *rt/net/sourceforge/jnlp/services/SingleInstanceLock.java: New
>> file.
>> *rt/net/sourceforge/jnlp/services/XServiceManagerStub.java: Add
>> SingleInstanceService to serviceNames. Create a new instance of
>> XSingleInstanceService as a privileged proxy.
>> *rt/net/sourceforge/jnlp/services/XSingleInstanceService.java: New
>> file.
>>
>> Any comments?
>
> Do you know that the first instance is connected to the same X server?
Just to be clear, even though the file names begin with X, they dont
have much to do with the X server. All Linux implementations of jnlp
services are prefixed with X in Netx.
To answer the question: no. This patch enforces a single instance per
user rather than per X session. Many other applications (such as
Firefox) do the same thing.
> What happens if a stale lock file is left behind by some earlier event?
This patch never cleans up the lock files. Each lock file contains a
port number where first instance of the application is listening. If no
application is listening at the port, then the file is assumed to be
stale and ignored/overwritten.
> Is it good to use NFS for the lock file? Would something in /tmp work
> better?
Honestly, I have no clue. Fwiw, Sun's JRE creates lock files under
~/.java/ . I have no issues with using /tmp if you think that would work
better.
Cheers,
Omair
More information about the distro-pkg-dev
mailing list