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