RFC: Netx - Implement SingeInstanceService

[Andrew Haley]

Omair Majid wrote:
> 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.

I am aware of that, of course: it's a famous longstanding Firefox bug.
What I don't know is whether jnlp is supposed to behave the same way;
I can't tell from the javadoc.  If it really is supposed to do that, fine.

>> 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.

Sounds good.

>> 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.

It probably is better, yes.

Andrew,