RFC: Netx - Implement SingeInstanceService

Omair Majid omajid at redhat.com
Mon Jun 22 09:50:14 PDT 2009


Andrew Haley wrote:
> 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.

Hmm... the javadocs arent clear to me either. But i just tried out the 
behaviour with Sun's javaws, and it results in a single instance per 
login. I am going to have to fix this patch.

>>> 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.
Ok, I will move it to /tmp

Thanks,
Omair



More information about the distro-pkg-dev mailing list