Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20855 > unrolled thread

single instance

Back to article view | Back to comp.lang.java.programmer

Contents

  single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-01 12:23 -0800
    Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-01 16:40 -0500
      Re: single instance Robert Tomsick <robert+usenet@tomsick.net> - 2013-01-03 01:20 -0500
    Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-03 00:55 -0800
      Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-03 19:31 -0800
        Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-03 19:49 -0800
        Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-03 19:56 -0800
          Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-04 12:18 -0500
            Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 10:22 -0800
              Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-04 13:44 -0500
                Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 11:03 -0800
                  Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-04 14:12 -0500
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-05 21:56 -0500
                  Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 19:22 -0500
                    Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:23 -0500
                      Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 20:43 -0500
                        Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:47 -0500
                          Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 20:51 -0500
                    Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:24 -0500
                      Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 20:46 -0500
                        Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:58 -0500
                          Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:08 -0500
                            Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:19 -0500
                              Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:31 -0500
                                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:41 -0500
                                  Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 22:00 -0500
                                    Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 22:11 -0500
                                      Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-07 00:23 -0500
                                        Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-02-24 18:20 -0500
                                Re: single instance Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-01-06 21:39 -0600
                                  Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-07 00:30 -0500
                        Re: single instance lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 08:53 +0000
                          Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-02-24 18:18 -0500
                            Re: single instance lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-25 08:31 +0000
                        Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-02-24 18:17 -0500
                    Re: single instance Lew <lewbloch@gmail.com> - 2013-01-06 17:32 -0800
                      Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 20:47 -0500
                        Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:53 -0500
                          Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:01 -0500
            Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-05 21:59 -0500
              Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 19:34 -0500
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:00 -0500
    Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-03 07:12 -0800
      Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-03 09:56 -0800
        Re: single instance Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-03 21:05 +0000
          Re: single instance Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-03 22:08 +0000
          Re: single instance "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-01-05 12:48 +0000
            Re: single instance Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-05 17:43 +0000
              Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-05 09:49 -0800
              Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-05 13:02 -0500
                Re: single instance Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-05 20:29 +0000
                  Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-05 19:07 -0800
                  Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 20:04 -0500
              Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-05 21:40 -0500
      Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-05 22:10 -0500
        Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-05 19:49 -0800
          Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-05 23:09 -0500
            Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 11:00 -0500
              Re: single instance Lew <lewbloch@gmail.com> - 2013-01-06 09:41 -0800
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 20:41 -0500
          Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-15 22:51 -0800
            Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-15 23:12 -0800
              Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-15 23:49 -0800
            Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-15 23:16 -0800
              Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-15 23:52 -0800
              Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-16 08:46 -0800
                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 10:46 -0800
                  Re: single instance markspace <markspace@nospam.nospam> - 2013-01-16 13:01 -0800
                  Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-16 17:10 -0800
            Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-15 23:50 -0800
              Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-16 00:13 -0800
                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 02:48 -0800
                  Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-16 07:28 -0800
                    Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 10:46 -0800
                      Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-16 16:53 -0800
                        Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 23:44 -0800
                          Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-17 07:03 -0800
                            Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 14:25 -0800
                              Re: single instance Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-17 16:31 -0800
                                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 22:11 -0800
                                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 22:36 -0800
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-16 13:34 -0500
            Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-16 08:45 -0800
            Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-16 13:29 -0500
              Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-16 17:14 -0800
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-16 20:20 -0500
                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 23:52 -0800
                Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 01:44 -0800
          Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-18 01:47 -0800
            Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-18 20:50 -0800
              Re: single instance Roedy Green <see_website@mindprod.com.invalid> - 2013-01-20 00:53 -0800
                Re: single instance Lew <lewbloch@gmail.com> - 2013-01-20 12:00 -0800
                  Re: single instance Knute Johnson <nospam@knutejohnson.com> - 2013-01-20 13:33 -0800
                    Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-02-24 18:12 -0500
                Re: single instance Arne Vajhøj <arne@vajhoej.dk> - 2013-01-20 21:33 -0500
        Re: single instance "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-01-06 13:34 +0000
    Re: single instance Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-04 10:26 -0800
      Re: single instance Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-04 14:04 -0500
    Re: single instance stledger@lanl.gov - 2013-01-16 14:51 -0800
      Re: single instance stledger@lanl.gov - 2013-01-16 15:09 -0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#20855 — single instance

What is the best way to ensure only a single instance of a Java
program is running.

I have used indicator files, but they can get screwed up if the user
kills the program without going through the standard shutdown.

Ideally, net new instance would just join the one already running.
This is pure GUI, so I am not worried about adding new command line
parms.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [next] | [standalone]

#20858

On 1/1/2013 3:23 PM, Roedy Green wrote:
> What is the best way to ensure only a single instance of a Java
> program is running.
>
> I have used indicator files, but they can get screwed up if the user
> kills the program without going through the standard shutdown.

1) Some platform specific native code invoked via JNI.

2) A file and if found the app prompts the user to abort or continue.

3) Using IP port.

> Ideally, net new instance would just join the one already running.

????

Arne

[toc] | [prev] | [next] | [standalone]

#20914

Arne Vajhøj wrote:

> On 1/1/2013 3:23 PM, Roedy Green wrote:
>> What is the best way to ensure only a single instance of a Java
>> program is running.
>>
>> I have used indicator files, but they can get screwed up if the user
>> kills the program without going through the standard shutdown.
> 
> 1) Some platform specific native code invoked via JNI.
> 
> 2) A file and if found the app prompts the user to abort or continue.
> 
> 3) Using IP port.

Ok, so first, if you're doing a JWS app, you might want to try this: 
http://pscode.org/jws/api.html#sis and do as specified.

Now if that's not the case then I'd go for a combination of #2 and #3.  You 
can't catch all the failure modes, but you can at least eliminate the "user 
loves kill -9" threat.

On launch of the first instance, your program could pick a random (high) 
port and open a socket.  It then writes the port number to a temporary file 
at a known location.

So now, on launch, all you have to do is check for the existance of that 
file.  If it's not there, you start as normal, see above.  If it is, you 
read the port number from the file, and try to connect to that socket.  If 
you succeed, you assume the program's already running and whine to the user.  
If you fail, you assume the program was killed prematurely, you nuke the 
temp file, and proceed as normal.

Of course that doesn't cover the case where your program gets whacked and 
something else starts listening on it in the meantime.  You can work around 
that by having your program identify itself via said socket.  It also 
doesn't handle the case where somebody deletes the temporary file while the 
app is running.  Still, I suppose it's at least something of a decent 
platform-specific way of ensuring you're not allowing multiple instances of 
your program.

All that said, I'd just use the typical pid file approach and assume that if 
the user decides to nuke the process they get to clean up the mess.

-Rob

[toc] | [prev] | [next] | [standalone]

#20919

On Tue, 01 Jan 2013 12:23:45 -0800, Roedy Green wrote:

> What is the best way to ensure only a single instance of a Java
> program is running.
> 
> I have used indicator files, but they can get screwed up if the user
> kills the program without going through the standard shutdown.
> 
> Ideally, net new instance would just join the one already running.
> This is pure GUI, so I am not worried about adding new command line
> parms.

In addition to the other fine advice you've gotten, you might want to look
at this thread:
http://stackoverflow.com/questions/3194227/named-system-mutex-in-java

As far as the sockets approach goes, you might be able to avoid the need of
dealing with a magic file or hard-coded socket port by using UDP multicast
with the SO_REUSEADDR option. This would allow your program to join to a
multicast port without interference from other programs, ensuring it's
ready to receive a UDP datagram sent on the channel from a new instance
searching for a prior existing instance.

Unfortunately, unlike the exclusive-create option available for a file,
there's no such built-in support for resolving race conditions in the
socket-based approach. Unless you are willing to go without a solution, or
are confident you can correctly design and implement a solution, you may
want to stick with the more user-driven approaches suggested.

But it's there in case you want to try. :)

Pete

[toc] | [prev] | [next] | [standalone]

#20937

On 1/3/2013 12:55 AM, Peter Duniho wrote:
> As far as the sockets approach goes, you might be able to avoid the need of
> dealing with a magic file or hard-coded socket port by using UDP multicast
> with the SO_REUSEADDR option. This would allow your program to join to a
> multicast port without interference from other programs, ensuring it's
> ready to receive a UDP datagram sent on the channel from a new instance
> searching for a prior existing instance.
>
> Unfortunately, unlike the exclusive-create option available for a file,
> there's no such built-in support for resolving race conditions in the
> socket-based approach. Unless you are willing to go without a solution, or
> are confident you can correctly design and implement a solution, you may
> want to stick with the more user-driven approaches suggested.
>
> But it's there in case you want to try. :)
>
> Pete

I'm not sure how you could do this without establishing what group and 
port your were going to use before hand.  But maybe that isn't what you 
were saying.

So what do you think of this implementation?  I did try to start two 
copies with a batch file and I could get them to fail on occasion.  I 
don't think it would be possible for a user to start two copies 
simultaneously though.

Thanks,

knute...

import java.awt.*;
import java.io.*;
import java.lang.reflect.*;
import java.net.*;
import java.nio.charset.*;
import java.util.*;
import javax.swing.*;

public class Exclusive implements Runnable {
     private final long myTime;
     private final MulticastSocket socket;
     private final InetAddress group;
     private final int port;

     private volatile boolean runFlag;
     private volatile Thread thread;

     public Exclusive(String ipStr, String portStr) throws IOException {
         myTime = System.currentTimeMillis();

         group = InetAddress.getByName(ipStr);
         port = Integer.parseInt(portStr);

         socket = new MulticastSocket(port);
         socket.joinGroup(group);
     }

     public void start() throws IOException {
         if (thread == null || !thread.isAlive()) {
             runFlag = true;
             thread = new Thread(this);
             thread.start();

             // send out my time
             String str = Long.toString(myTime);
             byte[] buf = str.getBytes(StandardCharsets.US_ASCII);
             DatagramPacket dp =
              new DatagramPacket(buf,buf.length,group,port);
             socket.send(dp);
         }
     }

     @Override public void run() {
         while (runFlag) {
             try {
                 // receive their time
                 byte[] buf = new byte[64];
                 DatagramPacket dp = new DatagramPacket(buf,buf.length);
                 socket.receive(dp);
                 String timeStr = new String(dp.getData(),dp.getOffset(),
                  dp.getLength(),StandardCharsets.US_ASCII);
                 long theirTime = Long.parseLong(timeStr);
                 // if we are seeing our own packet, do nothing
                 if (theirTime == myTime) {
                 // if their time is before my time, we need to shut down
                 } else if (theirTime < myTime) {
                     stop();
                     shutdownHook();
                 // if their time is after my time, send out my time
                 } else if (theirTime > myTime) {
                     String str = Long.toString(myTime);
                     buf = str.getBytes(StandardCharsets.US_ASCII);
                     dp = new DatagramPacket(buf,buf.length,group,port);
                     socket.send(dp);
                 }
             } catch (IOException|NumberFormatException ex) {
                 ex.printStackTrace();
                 stop();
             }
         }
     }

     private void stop() {
         if (thread != null && thread.isAlive()) {
             runFlag = false;
             if (socket != null)
                 socket.close();
         }

         // signal the waitFor() method to stop waiting
         synchronized (this) {
             notify();
         }
     }

     // wait for two seconds to delay program startup until we have
     //  time to determine if there is another copy running.
     //  returns true if no other copy is running.
     public synchronized boolean waitFor() throws InterruptedException {
         wait(2000);

         return runFlag;
     }

     public void shutdownHook() {
         // can't use invokeLater()
         try {
             EventQueue.invokeAndWait(new Runnable() {
                 public void run() {
                     JOptionPane.showMessageDialog(null,
                      "Another Copy of this Program is Already Running",
                      "Start Inhibited",JOptionPane.ERROR_MESSAGE);
                 }
             });
         } catch (InterruptedException|InvocationTargetException ex) {
             ex.printStackTrace();
         }
     }

     public static void main(String[] args) {
         try {
             Exclusive e = new Exclusive("227.228.229.230","23222");
             e.start();
             if (e.waitFor())
                 System.out.println("no other copy running!");
             else
                 System.out.println("another copy is running");

         } catch (IOException|InterruptedException ex) {
             // probably don't want to start if you get an exception either
             ex.printStackTrace();
         }
     }
}

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#20938

On Thu, 03 Jan 2013 19:31:37 -0800, Knute Johnson wrote:

> I'm not sure how you could do this without establishing what group and 
> port your were going to use before hand.  But maybe that isn't what you 
> were saying.

The point is that with that technique, there shouldn't be a need to have a
unique port.  Multiple clients can listen on the same port/group without
conflict.

> So what do you think of this implementation?  I did try to start two 
> copies with a batch file and I could get them to fail on occasion.  I 
> don't think it would be possible for a user to start two copies 
> simultaneously though.

It looks like a good start.  I will point out that there's no guarantee
that the "myTime" value for each process will be unique, so one process
could misidentify the other process's message as its own.  You need some
form of tie-breaker, or a better unique ID that can be used (e.g. GUID).

That conflict could be related to the failures you noted when testing the
code.

The code itself has places that seem like could be improved. For example,
duplicated code to send the local "myTime" value ought to be in a method
called by the two places where that operation is done. I also don't
understand the check for "thread != null" and "thread.isAlive()" in the
"stop()" method, but maybe I'm just overlooking something (as near as I can
tell, "stop()" is called only when those conditions are assured of being
true).

But it's the gist of what I was describing.

Pete

[toc] | [prev] | [next] | [standalone]

#20939

On Thu, 03 Jan 2013 19:31:37 -0800, Knute Johnson wrote:

> [...]
> So what do you think of this implementation?  I did try to start two 
> copies with a batch file and I could get them to fail on occasion.  I 
> don't think it would be possible for a user to start two copies 
> simultaneously though.

Oh, and it should go without saying that in a real implementation, each
program would have a way to include a unique identifier (i.e. similar to
the name one would use for a named mutex on Windows) in the transmitted
message, to insure against two completely different programs that are using
the same "exclusive" implementation from conflicting with each other.

But I'll say it anyway. :)

It is important to keep in mind that even this approach is not 100%
reliable.  UDP messages are not guaranteed delivery, so the earlier
instance could fail to receive a request from a later instance, or the
later instance could fail to receive the reply.

I think that between processes on the same machine, the chances of such a
failure are extremely slim.  UDP datagrams are usually dropped due to
congestion, lack of process buffer space, that sort of thing, none of which
should be an issue in this scenario.  But nothing about the UDP protocol or
socket API actually guarantees delivery.

Pete

[toc] | [prev] | [next] | [standalone]

#20944

On Thu, 3 Jan 2013 19:56:37 -0800, Peter Duniho wrote:

> On Thu, 03 Jan 2013 19:31:37 -0800, Knute Johnson wrote:
> 
>> [...]
>> So what do you think of this implementation?  I did try to start two 
>> copies with a batch file and I could get them to fail on occasion.  I 
>> don't think it would be possible for a user to start two copies 
>> simultaneously though.
> 
> Oh, and it should go without saying that in a real implementation, each
> program would have a way to include a unique identifier (i.e. similar to
> the name one would use for a named mutex on Windows) in the transmitted
> message, to insure against two completely different programs that are using
> the same "exclusive" implementation from conflicting with each other.
> 
> But I'll say it anyway. :)

Why not just use the process PID as unique identifier?

> It is important to keep in mind that even this approach is not 100%
> reliable.  UDP messages are not guaranteed delivery,

This is loopback interface we're talking about, not the wild wild internet.

In any event, the error message that was proposed isn't a very useful way
of handling the situation. I'd suggest that once the old and new instance
are in communication and agree on which is which:

- The new instance sends the old its invocation command-line, then quietly
  terminates.
- The old interprets this command-line and e.g. opens named documents in
  additional document windows. If those are JFrames the last one should
  automatically wind up with window focus.
- If those are JInternalFrames, or there were no new documents to open, the
  old instance's main/most recently active JFrame grabs window focus.

So, if you just double-click on the program somewhere, the existing
instance jumps to the front of the window stack. If you double-click on a
document associated with the program, it opens in the existing instance.
This pattern of behavior is common in native apps that don't like running
in multiple instances, and so replicating it would be best given the
principle of least astonishment.

Wagging a naughty-finger in the user's face because they double-clicked a
document file associated with an already-open application, on the other
hand, and forcing them to instead drag and drop it into the existing
instance (or, worse, switch to the existing instance to use its File Open
menu and re-browse the directory tree) would violate the same principle.

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#20945

On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:

> On Thu, 3 Jan 2013 19:56:37 -0800, Peter Duniho wrote:
> 
>> On Thu, 03 Jan 2013 19:31:37 -0800, Knute Johnson wrote:
>> 
>>> [...]
>>> So what do you think of this implementation?  I did try to start two 
>>> copies with a batch file and I could get them to fail on occasion.  I 
>>> don't think it would be possible for a user to start two copies 
>>> simultaneously though.
>> 
>> Oh, and it should go without saying that in a real implementation, each
>> program would have a way to include a unique identifier (i.e. similar to
>> the name one would use for a named mutex on Windows) in the transmitted
>> message, to insure against two completely different programs that are using
>> the same "exclusive" implementation from conflicting with each other.
>> 
>> But I'll say it anyway. :)
> 
> Why not just use the process PID as unique identifier?

You misunderstand.  The "unique identifier" is not per-process, but rather
per-program.  Each program that uses this implementation needs to use a
unique identifier, so that each _instance_ of a given program is using the
_same_ identifier, so as to distinguish responses that might come from
instances of _other_ programs (i.e. not conflict with those instances of
other programs).

Even if I was talking about a unique per-process identifier, process ID
isn't really all that great, because getting the process ID requires
platform-specific code. Not as complicated as using platform-specific code
for the whole implementation (e.g. named mutex on Windows), but still not
platform-agnostic.

>> It is important to keep in mind that even this approach is not 100%
>> reliable.  UDP messages are not guaranteed delivery,
> 
> This is loopback interface we're talking about, not the wild wild internet.

Maybe you should have kept reading, on to the next paragraph where I wrote:

>> I think that between processes on the same machine, the chances of such a
>> failure are extremely slim.  UDP datagrams are usually dropped due to
>> congestion, lack of process buffer space, that sort of thing, none of which
>> should be an issue in this scenario.  But nothing about the UDP protocol or
>> socket API actually guarantees delivery.

That said, just because the chances of a dropped datagram are lower,
doesn't mean that chance has gone away completely.

> In any event, the error message that was proposed isn't a very useful way
> of handling the situation. [...]

Each program may have unique needs. As far as your suggestion to pass
command line from one to the other, if you'd read the original post you'd
realize that it was specifically stated that no command line arguments are
present.

As far as making "the existing instance jump to the front of the window
stack", again AFAIK there's no platform-independent way to do that.  It' a
fine implementation idea (even though the OP did not state it as a
requirement), but Java simply doesn't provide a standard, general-purpose
API that can be used to do that.

Fact is, due to Java's "least-common denominator" philosophy, there are
times users have to accept less-than-optimal behaviors from their Java
programs, if those programs are to truly remain platform-independent. That
includes "wagging a naughty-finger in the user's face..." on occasion
rather than automatically taking care of the user's needs for them.

Pete

[toc] | [prev] | [next] | [standalone]

#20948

On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:

> On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:
> 
>> Why not just use the process PID as unique identifier?
> 
> You misunderstand.

I do not.

> The "unique identifier" is not per-process, but rather per-program.

Then you should have just said so. Use argument 0 of the command line then
-- that should be the path of the executable. Then each install of the
application will be single-instance, but by making more than one install
the user could have multiple instances. These instances would have separate
sets of settings files, however, being from separate installs, so one of
the two big reasons for inhibiting multi-instances doesn't apply there.
(The other is user convenience -- opening a load of documents and having
them all open in the same containing window, with maybe special drag and
drop options available between them, and without as much memory use as if
each had a separate process. If the user deliberately chooses to circumvent
this for some reason, though, one should defer to the user's wishes having
provided a reasonable default for the common case of a single install.)

> Even if I was talking about a unique per-process identifier, process ID
> isn't really all that great, because getting the process ID requires
> platform-specific code.

1. Getting argument 0 doesn't, which is what now seems like the best idea.
2. Isn't there a Process class in the Java API as of a few versions ago
   that interacts with the host's job control?

> Not as complicated as using platform-specific code
> for the whole implementation (e.g. named mutex on Windows), but still not
> platform-agnostic.

The concept of a PID is platform-agnostic -- all Unices seem to have it,
MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be surprising
if there isn't a platform-agnostic way to get at PIDs -- a POSIX call that
Windows supports, most likely.

>>> It is important to keep in mind that even this approach is not 100%
>>> reliable.  UDP messages are not guaranteed delivery,
>> 
>> This is loopback interface we're talking about, not the wild wild internet.
> 
> Maybe you should have kept reading, [rest deleted unread]

You will need to be more polite and less judgmental if you want me to read
more of what you have to say. You catch more flies with honey than you do
with vinegar, and repeatedly insinuating that I did various things wrong or
should have done X instead of Y or etc. constitutes vinegar. Especially
when done before a live studio audience.

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#20949

On Fri, 4 Jan 2013 13:44:56 -0500, Twirlip of the Mists wrote:

> On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:
> 
>> On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:
>> 
>>> Why not just use the process PID as unique identifier?
>> 
>> You misunderstand.
> 
> I do not.

Not now, it appears.  Clearly you did before.

>> The "unique identifier" is not per-process, but rather per-program.
> 
> Then you should have just said so. [...]

I did say so:

>> Oh, and it should go without saying that in a real implementation, each
>> program would have a way to include a unique identifier (i.e. similar to
>> the name one would use for a named mutex on Windows) in the transmitted
>> message, to insure against two completely different programs that are using
>> the same "exclusive" implementation from conflicting with each other.

Just because you incorrectly thought I wrote "each PROCESS" instead of
"each PROGRAM", that doesn't mean I didn't already write what I meant to
write.

> [...]
> You will need to be more polite and less judgmental if you want me to read
> more of what you have to say.

You seem to have a log in your eye.  You might want to get that looked at
before you work on removing splinters from mine.

[toc] | [prev] | [next] | [standalone]

#20951

On Fri, 4 Jan 2013 11:03:02 -0800, Peter Duniho wrote:

> On Fri, 4 Jan 2013 13:44:56 -0500, Twirlip of the Mists wrote:
> 
>> On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:
>> 
>>> You misunderstand.
>> 
>> I do not.
> 
> Not now, it appears.  Clearly you did before.

...

>> Then you should have just said so. [...]
> 
> I did say so

...

> Just because you incorrectly th[deleted]

...

> You seem to have a log in your eye.[nuke]

[plonk]

...

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#21006

On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
> On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:
>
>> On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:
>>
>>> Why not just use the process PID as unique identifier?
>>
>> You misunderstand.
>
> I do not.

Obviously you did.

>> The "unique identifier" is not per-process, but rather per-program.
>
> Then you should have just said so.

He did.

<quote>
Oh, and it should go without saying that in a real implementation, each
program would have a way to include a unique identifier (i.e. similar to
the name one would use for a named mutex on Windows) in the transmitted
message, to insure against two completely different programs that are using
the same "exclusive" implementation from conflicting with each 
other.</quote>

"... each program would have a way to include a unique identifier ...
to insure against two completely different programs ... conflicting
with each other"

Count the frequency of "program" and "process".

>> Not as complicated as using platform-specific code
>> for the whole implementation (e.g. named mutex on Windows), but still not
>> platform-agnostic.
>
> The concept of a PID is platform-agnostic -- all Unices seem to have it,
> MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be surprising
> if there isn't a platform-agnostic way to get at PIDs -- a POSIX call that
> Windows supports, most likely.

*nix and Windows support does not mean platform-agnostic.

>>>> It is important to keep in mind that even this approach is not 100%
>>>> reliable.  UDP messages are not guaranteed delivery,
>>>
>>> This is loopback interface we're talking about, not the wild wild internet.
>>
>> Maybe you should have kept reading, [rest deleted unread]
>
> You will need to be more polite and less judgmental if you want me to read
> more of what you have to say.

Peter most likely does not care whether you read his posts or not.

Arne

[toc] | [prev] | [next] | [standalone]

#21083

On Sat, 05 Jan 2013 21:56:37 -0500, Arne Vajhøj wrote:

> On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
>> On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:
>>
>>> On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:
>>>
>>>> Why not just use the process PID as unique identifier?
>>>
>>> You misunderstand.
>>
>> I do not.
> 
> Obviously you did.

No, I did not.

>>> The "unique identifier" is not per-process, but rather per-program.
>>
>> Then you should have just said so.
> 
> He did.

He didn't.

> Count the frequency of "program" and "process".

Counting the number of occurrences of some words without considering their
context is a meaningless metric.

>> The concept of a PID is platform-agnostic -- all Unices seem to have it,
>> MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be surprising
>> if there isn't a platform-agnostic way to get at PIDs -- a POSIX call that
>> Windows supports, most likely.
> 
> *nix and Windows support does not mean platform-agnostic.

1. When was the last time you, or anyone you know, bought or saw anyone
   using a computer or other gadget that wasn't either Apple, Windows, or
   some flavor of Unix?

2. How would you develop an OS without the concept of a PID? (No, the sucky
   iPhone "OS" doesn't count, since it DOESN'T MULTITASK. :P)

3. Does anyone tend to make OSen (iPhone "OS" again does not count) that
   *aren't* fairly POSIXy anymore?

4. And before you bring up some obscure legacy OS on some archaic mainframe
   that some large banking institution in some obscure corner of the world
   is still using to run some old bit of business logic for which they've
   long since lost all the source code, recall that the context here is
   *development of some new software*. Nobody sane develops *new* software
   for clunkers like that -- they develop it for their farm of Unix servers
   or their ten thousand cubicle boxen running Windows, even if maybe it
   uses some network to get some service from the legacy mainframe.

>>>>> It is important to keep in mind that even this approach is not 100%
>>>>> reliable.  UDP messages are not guaranteed delivery,
>>>>
>>>> This is loopback interface we're talking about, not the wild wild internet.
>>>
>>> Maybe you should have kept reading, [rest deleted unread]
>>
>> You will need to be more polite and less judgmental if you want me to read
>> more of what you have to say.
> 
> Peter most likely does not care whether you read his posts or not.

It's starting to look like you don't either, which naturally causes one to
question why you bother writing them.

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#21093

On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
> On Sat, 05 Jan 2013 21:56:37 -0500, Arne Vajhøj wrote:
>
>> On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
>>> On Fri, 4 Jan 2013 10:22:44 -0800, Peter Duniho wrote:
>>>
>>>> On Fri, 4 Jan 2013 12:18:59 -0500, Twirlip of the Mists wrote:
>>>>
>>>>> Why not just use the process PID as unique identifier?
>>>>
>>>> You misunderstand.
>>>
>>> I do not.
>>
>> Obviously you did.
>
> No, I did not.

That has clearly been demonstrated.

>
>>>> The "unique identifier" is not per-process, but rather per-program.
>>>
>>> Then you should have just said so.
>>
>> He did.
 >>
>> <quote>
>> Oh, and it should go without saying that in a real implementation, each
>> program would have a way to include a unique identifier (i.e. similar to
>> the name one would use for a named mutex on Windows) in the transmitted
>> message, to insure against two completely different programs that are using
>> the same "exclusive" implementation from conflicting with each other.</quote>
>>
>> "... each program would have a way to include a unique identifier ...
>> to insure against two completely different programs ... conflicting
>> with each other"
>
> He didn't.
>
>> Count the frequency of "program" and "process".
>
> Counting the number of occurrences of some words without considering their
> context is a meaningless metric.

Well if a piece of text mentions the word program twice and do not
mention the word process, then it is a pretty good metric that
he is talking about programs not processes.

Arne

[toc] | [prev] | [next] | [standalone]

#21099

On Sun, 06 Jan 2013 20:23:46 -0500, Arne Vajhøj wrote:

> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>> No, I did not.
> 
> That has clearly been demonstrated.

Good that you've seen the light at last and now agree with me.

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#21102

On 1/6/2013 8:43 PM, Twirlip of the Mists wrote:
> On Sun, 06 Jan 2013 20:23:46 -0500, Arne Vajhøj wrote:
>
>> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>>> No, I did not.
>>
>> That has clearly been demonstrated.
>
> Good that you've seen the light at last and now agree with me.

Actually the "that" were intended to refer to Peter's claim not yours.

Arne

[toc] | [prev] | [next] | [standalone]

#21104

On Sun, 06 Jan 2013 20:47:52 -0500, Arne Vajhøj wrote:

> On 1/6/2013 8:43 PM, Twirlip of the Mists wrote:
>> On Sun, 06 Jan 2013 20:23:46 -0500, Arne Vajhøj wrote:
>>
>>> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>>>> No, I did not.
>>>
>>> That has clearly been demonstrated.
>>
>> Good that you've seen the light at last and now agree with me.
> 
> Actually the "that" were intended to refer to Peter's claim not yours.

Aww, and now you're backpedaling away from the brink of conceding defeat.
So cute. Too bad you didn't start until after you'd already gone over the
side. :)

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

#21094

On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
> On Sat, 05 Jan 2013 21:56:37 -0500, Arne Vajhøj wrote:
>> On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
>>> The concept of a PID is platform-agnostic -- all Unices seem to have it,
>>> MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be surprising
>>> if there isn't a platform-agnostic way to get at PIDs -- a POSIX call that
>>> Windows supports, most likely.
>>
>> *nix and Windows support does not mean platform-agnostic.
>
> 1. When was the last time you, or anyone you know, bought or saw anyone
>     using a computer or other gadget that wasn't either Apple, Windows, or
>     some flavor of Unix?

Yesterday.

> 2. How would you develop an OS without the concept of a PID? (No, the sucky
>     iPhone "OS" doesn't count, since it DOESN'T MULTITASK. :P)

Well - iOS is an OS.

It is possible to develop an OS without PID's.

DOS did not have PID's.

> 3. Does anyone tend to make OSen (iPhone "OS" again does not count) that
>     *aren't* fairly POSIXy anymore?

There are not that much point in not counting iOS.

But why do you keep excluding it?

iOS is POSIXy!

> 4. And before you bring up some obscure legacy OS on some archaic mainframe
>     that some large banking institution in some obscure corner of the world
>     is still using to run some old bit of business logic for which they've
>     long since lost all the source code, recall that the context here is
>     *development of some new software*. Nobody sane develops *new* software
>     for clunkers like that -- they develop it for their farm of Unix servers
>     or their ten thousand cubicle boxen running Windows, even if maybe it
>     uses some network to get some service from the legacy mainframe.

New code still get developed for mainframes.

And sane developers develop software for the platforms
they get paid to develop for.

BTW, z/OS is also POSIXy!

But nothing of this really matters. A feature being support by all
common platforms and a feature being platform-agnostic are two
different things.

Arne

[toc] | [prev] | [next] | [standalone]

#21101

On Sun, 06 Jan 2013 20:24:29 -0500, Arne Vajhøj wrote:

> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>> On Sat, 05 Jan 2013 21:56:37 -0500, Arne Vajhøj wrote:
>>> On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
>>>> The concept of a PID is platform-agnostic -- all Unices seem to have it,
>>>> MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be surprising
>>>> if there isn't a platform-agnostic way to get at PIDs -- a POSIX call that
>>>> Windows supports, most likely.
>>>
>>> *nix and Windows support does not mean platform-agnostic.
>>
>> 1. When was the last time you, or anyone you know, bought or saw anyone
>>     using a computer or other gadget that wasn't either Apple, Windows, or
>>     some flavor of Unix?
> 
> Yesterday.

What operating system was it? Do you think your experience at all typical
of the general population?

>> 2. How would you develop an OS without the concept of a PID? (No, the sucky
>>     iPhone "OS" doesn't count, since it DOESN'T MULTITASK. :P)
> 
> Well - iOS is an OS.
> 
> It is possible to develop an OS without PID's.
> 
> DOS did not have PID's.

DOS also lacked multitasking.

And lacking multitasking makes the issue of multiple concurrent instances
of a single program rather moot, wouldn't you say?

>> 3. Does anyone tend to make OSen (iPhone "OS" again does not count) that
>>     *aren't* fairly POSIXy anymore?
> 
> There are not that much point in not counting iOS.

See above.

> iOS is POSIXy!

That, if true, just works in my argument's favor.

>> 4. And before you bring up some obscure legacy OS on some archaic mainframe
>>     that some large banking institution in some obscure corner of the world
>>     is still using to run some old bit of business logic for which they've
>>     long since lost all the source code, recall that the context here is
>>     *development of some new software*. Nobody sane develops *new* software
>>     for clunkers like that -- they develop it for their farm of Unix servers
>>     or their ten thousand cubicle boxen running Windows, even if maybe it
>>     uses some network to get some service from the legacy mainframe.
> 
> New code still get developed for mainframes.

I said "nobody sane", not "nobody". :)

> But nothing of this really matters. A feature being support by all
> common platforms and a feature being platform-agnostic are two
> different things.

All common platforms is necessary, and in practice sufficient. Your
strictly-exact notion of "platform-agnostic" is so restrictive as to be
meaningless -- what would compile and run on both Windows 8 and Babbage's
difference engine?

-- 
Hexapodia is the key insight.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web