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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#21085

On Sat, 05 Jan 2013 21:59:19 -0500, Arne Vajhøj wrote:

> On 1/4/2013 12:18 PM, Twirlip of the Mists wrote:
>> On Thu, 3 Jan 2013 19:56:37 -0800, Peter Duniho wrote:
>>> 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.
> 
> Which does not contradict Peters statement.

Sure it does. Where is the packet going to run into congestion and get
dropped? What network cable will it travel over that might be damaged or
cut ahead of its path? It's probably more likely to try to use your
short-range baby monitor and get a busy signal.

-- 
Hexapodia is the key insight.

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

#21089

On 1/6/2013 7:34 PM, Twirlip of the Mists wrote:
> On Sat, 05 Jan 2013 21:59:19 -0500, Arne Vajhøj wrote:
>> On 1/4/2013 12:18 PM, Twirlip of the Mists wrote:
>>> On Thu, 3 Jan 2013 19:56:37 -0800, Peter Duniho wrote:
>>>> 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.
>>
>> Which does not contradict Peters statement.
>
> Sure it does. Where is the packet going to run into congestion and get
> dropped? What network cable will it travel over that might be damaged or
> cut ahead of its path? It's probably more likely to try to use your
> short-range baby monitor and get a busy signal.

Read the RFC.

No guarantee.

And not mention of an exception for loopback.

That you can not imagine it not being delivered means
nothing.

Arne

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

#20922

On Tue, 01 Jan 2013 12:23:45 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

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

I was expecting this to be a method in some obscure corner of the Java
API.  I was bracing myself for the usual RTFM (read all docs end to
end and miss nothing).
 
The only technique that does not have some major drawback is the UDP
broadcast, but I don't fully understand it yet.

I have recorded your ideas in my essay at
http://mindprod.com/jgloss/singleinstance.html
-- 
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] | [prev] | [next] | [standalone]

#20926

On Thu, 03 Jan 2013 07:12:47 -0800, Roedy Green wrote:

> On Tue, 01 Jan 2013 12:23:45 -0800, Roedy Green
> <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
> 
>>What is the best way to ensure only a single instance of a Java
>>program is running.
> 
> I was expecting this to be a method in some obscure corner of the Java
> API.  I was bracing myself for the usual RTFM (read all docs end to
> end and miss nothing).
>  
> The only technique that does not have some major drawback is the UDP
> broadcast, but I don't fully understand it yet.

I wouldn't say the UDP approach has no major drawback.  It's likely to be
the most portable and reliable, _if implemented correctly_. But it's a
non-trivial problem to do that, due to the race condition issue I
mentioned.

Granted, implemented once correctly, then you can reuse the solution over
and over.  I suppose at that point, it has no major drawbacks. :)

Note that if you're willing to constrain the problem by supporting the
feature only on certain platforms, you can write platform-specific code
accessed through JNI.  For example, on Windows the usual approach to this
problem is to create a named mutex (an OS-supported object).

I would guess that Unix and Linux have similar OS-supported techniques (and
may even be the same for those two).  So writing two, maybe three at the
most, platform-specific solutions would give you cross-platform support for
the vast majority of clients.

Pete

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

#20927

On Thu, 03 Jan 2013 09:56:27 -0800, Peter Duniho wrote:

> I would guess that Unix and Linux have similar OS-supported techniques
> (and may even be the same for those two).  So writing two, maybe three
> at the most, platform-specific solutions would give you cross-platform
> support for the vast majority of clients.
>
A common approach for *NIXen is to use a file with a known absolute 
pathname that contains the process PID. The clever trick is that the 
program that creates the file immediately closes and reopens it for 
reading and then deletes the file without closing it: this works because 
file deletion is deferred until there are no longer any processes that 
have the file open. When a process dies or is killed, all the files it 
had open are closed.

If the file exists and has a different pid to the checker, then another 
copy is running. There is no clean-up needed: if the user kills the 
program the file vanishes because it only remains in existence as long as 
at least one process has the file open.

As well as Linux and Unices, this works for a number of other OSen: its 
certainly good for BSB (and hence OS X), Stratus VOX and, IIRC, 
Microware's OS-9.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#20932

On Thu, 03 Jan 2013 21:05:02 +0000, Martin Gregorie wrote:

> As well as Linux and Unices, this works for a number of other OSen: its
> certainly good for BSB (and hence OS X), Stratus VOX and, IIRC,
> Microware's OS-9.

Gaaah! for 'BSB' read BSD.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#20978

Martin Gregorie wrote:

> A common approach for *NIXen is to use a file with a known absolute
> pathname that contains the process PID. The clever trick is that the
> program that creates the file immediately closes and reopens it for
> reading and then deletes the file without closing it: this works because
> file deletion is deferred until there are no longer any processes that
> have the file open. When a process dies or is killed, all the files it
> had open are closed.

I don't believe this would work on any variant on *NIX that I've used.  When a 
process deletes a file that it (or some other) process has open, then the file 
handles stay valid, but the /filename/ is removed from the file system, the 
file itself remaining on-disk, but no longer accessible.  (More accurately, 
/that/ filename is removed from the FS, there may well be other links to the 
same physical file with different names elsewhere.  Once all the links have 
gone, and all the processes have either died or closed their open file 
descriptors, the physical file is removed from the disk).

This is an old technique for generating almost perfectly reliable temporary 
files, but it can't work for creating /shared/ temporary files (without a lot 
more work and co-ordination between processes) precisely because the file 
becomes "invisible" as soon as it is unlinked.

There may be something added to modern Linux (or whatever) that makes it easier 
to create shared temporary files (not the requirement here, of course).  But 
there's nothing in "classic" *NIX (say from around the time of SysV).

    -- chris 

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

#20990

On Sat, 05 Jan 2013 12:48:41 +0000, Chris Uppal wrote:

> There may be something added to modern Linux (or whatever) that makes it
> easier to create shared temporary files (not the requirement here, of
> course).  But there's nothing in "classic" *NIX (say from around the
> time of SysV).
>
Correct: test C code written and checked to prove your point. The Stratus 
VOS OS left the file in place: you could see it from list_directory after 
it had been deleted, but Linux doesn't do that.

However, the automatic cleanup is easy enough to manage from C via the 
atexit() function, which is very to use since you just call atexit() near 
the start of the main() function: once atexit() has registered your exit 
action(s) you get on with whatever the program is meant to do in the 
knowledge that these actions will happen regardless of how the program 
exits (power failures and system crashes excluded). 

This works for Linux and all Unices since SVR4. atexit() is documented in 
the O'Reilly Lion book. The current kernel 3.6 Linux manpage says 
atexit() conforms to SVR4, 4.3BSD, C89, C99 and POSIX.1-2001.

It looks as though the nearest we can come to this in Java is via 
try...finally blocks.

However, I'm wondering if the finally block would always execute, e.g. if 
the try...finally block is in the main() method of a program that exits 
leaving thread(s) running to do the work, does the finally block still 
get still run when the last thread(s) terminates?  I had a fairly cursory 
look at JLS 14.20.1 but it wasn't clear on this point.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#20991

On Sat, 5 Jan 2013 17:43:15 +0000 (UTC), Martin Gregorie wrote:

> [...]
> However, I'm wondering if the finally block would always execute, e.g. if 
> the try...finally block is in the main() method of a program that exits 
> leaving thread(s) running to do the work, does the finally block still 
> get still run when the last thread(s) terminates?  I had a fairly cursory 
> look at JLS 14.20.1 but it wasn't clear on this point.

Well, even if you can handle termination by exception in a Java program, an
implementation that relies on execution from within the process won't be
able to do anything if the process is terminated externally.

That's why an OS-supported technique is preferable: it works whenever the
process ends, regardless of reason.

But since there are also arguments in favor of using a platform-independent
solution, sometimes the trade-off may be acceptable, even if the end result
isn't perfect.

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

#20993

On Sat, 5 Jan 2013 17:43:15 +0000 (UTC), Martin Gregorie wrote:

> On Sat, 05 Jan 2013 12:48:41 +0000, Chris Uppal wrote:
> 
>> There may be something added to modern Linux (or whatever) that makes it
>> easier to create shared temporary files (not the requirement here, of
>> course).  But there's nothing in "classic" *NIX (say from around the
>> time of SysV).
>
> Correct: test C code written and checked to prove your point. The Stratus 
> VOS OS left the file in place: you could see it from list_directory after 
> it had been deleted, but Linux doesn't do that.
> 
> However, the automatic cleanup is easy enough to manage from C via the 
> atexit() function, which is very to use since you just call atexit() near 
> the start of the main() function: once atexit() has registered your exit 
> action(s) you get on with whatever the program is meant to do in the 
> knowledge that these actions will happen regardless of how the program 
> exits (power failures and system crashes excluded). 

In other words, atexit is a fine way to implement this if you're happy with
a solution that fails and leaves a stale lock every time there's a
thunderstorm. :)

> It looks as though the nearest we can come to this in Java is via 
> try...finally blocks.
> 
> However, I'm wondering if the finally block would always execute, e.g. if 
> the try...finally block is in the main() method of a program that exits 
> leaving thread(s) running to do the work, does the finally block still 
> get still run when the last thread(s) terminates?  I had a fairly cursory 
> look at JLS 14.20.1 but it wasn't clear on this point.

The finally will execute when the main method exits, which, in a GUI
program, is probably long *before* the app terminates. It won't execute at
all in a console app that ends via System.exit(0) or similar without
falling off the end of main. It will execute if it falls off the end of
main however.

Java has Runtime.getRuntime().addShutdownHook(Thread x), which *will* run
on System.exit(0) and *won't* run immediately if the startup thread of a
GUI app falls off the end of main.

However, both a main finally block and addShutdownHook are vulnerable to
the aforementioned thunderstorm, and, additionally, to all of the
following:

* VM crash
* Crash (e.g. segfault) in native method
* kill -9, force-quit, Task Manager End Task, and equivalents

C's atexit is probably vulnerable to the latter two, mitigatable only
partially by registering signal handlers.

The only thing I can think of that even the thunderstorm won't fuck up is
an active system where the lockfile is only considered valid if some
associated "heartbeat" is still going, so, the lockfile invalidates on a
deadman switch even if not deleted. An associated pulse you can test for on
a loopback port was already suggested elsewhere in this thread. Having the
lockfile contents be a representation of a time, updated by the live
application every 1 second, and treated as invalid if it's stale by at
least 5 seconds, is another possibility -- a fresh instance can simply
overwrite the file and carry on if it's older than 5 seconds, and otherwise
wait (5 - file's age at time of startup-attempt) seconds to see if the file
changes, then do whatever's appropriate based on whether it did or not. (On
Unix, at least, you can just "touch" the file to "heartbeat" and test its
modification time to "take a pulse".)

-- 
Hexapodia is the key insight.

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

#20997

On Sat, 05 Jan 2013 13:02:57 -0500, Twirlip of the Mists wrote:

> C's atexit is probably vulnerable to the latter two, mitigatable only
> partially by registering signal handlers.
>
I don't think any of these approaches are immune to system crashes, but 
should be good enough to prevent single processes, whether launched by a 
user or automatically by the system, from running more copies that are 
wanted.

I'd normally use a shell script or programmed equivalent to launch a more 
complex set of processes. Its first action would be to assume a crash had 
ocurred and do a full clean-up: if the system had shut down normally the 
clean-up would still run but would not find anything to do.

> The only thing I can think of that even the thunderstorm won't fuck up
> is an active system where the lockfile is only considered valid if some
> associated "heartbeat" is still going, so, the lockfile invalidates on a
> deadman switch even if not deleted.
>
Yes, that would work too: though it sounds as if the mere existence of a 
small 'heartbeat' process could obviate the need for a lockfile: if the 
heartbeat process is running and agrees that the limit for your process 
type hasn't been reached, your process can start. In all other 
circumstances it can't start. As a bonus, if all processes periodically 
checked the heartbeat process state and exited of the heartbeat said 
'die', it could also be used as a convenient way to shut a complex system 
down.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#21008

On Sat, 5 Jan 2013 20:29:52 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :

>I don't think any of these approaches are immune to system crashes, but 
>should be good enough to prevent single processes, whether launched by a 
>user or automatically by the system, from running more copies that are 
>wanted.

With windows perhaps you start a small service on every boot. When it
starts, it can presume nothing is running. You could even interrogate
at the command line it if is safe to start a new instance, rather than
loading it and discovering only after it had started execution it
should die..

One feature of this system is you want it to check as early as
possible in the load process if there is another instance.

The other is a way of passing command line parms of a second instance
to the first in some uniform way.

It might be nice if the mechanism worked for code in any language.
-- 
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] | [prev] | [next] | [standalone]

#21090

On Sat, 5 Jan 2013 20:29:52 +0000 (UTC), Martin Gregorie wrote:

> On Sat, 05 Jan 2013 13:02:57 -0500, Twirlip of the Mists wrote:
> 
>> C's atexit is probably vulnerable to the latter two, mitigatable only
>> partially by registering signal handlers.
>>
> I don't think any of these approaches are immune to system crashes, but 
> should be good enough to prevent single processes, whether launched by a 
> user or automatically by the system, from running more copies that are 
> wanted.

As I concluded at the end of my post.

> I'd normally use a shell script or programmed equivalent to launch a more 
> complex set of processes. Its first action would be to assume a crash had 
> ocurred and do a full clean-up: if the system had shut down normally the 
> clean-up would still run but would not find anything to do.

That may make sense for a lot of systems.

>> The only thing I can think of that even the thunderstorm won't fuck up
>> is an active system where the lockfile is only considered valid if some
>> associated "heartbeat" is still going, so, the lockfile invalidates on a
>> deadman switch even if not deleted.
>>
> Yes, that would work too: though it sounds as if the mere existence of a 
> small 'heartbeat' process could obviate the need for a lockfile:

Uh, something still has to point to the location of the heartbeat process.
Either that needs a fixed but configurable port, or else the lockfile (or
some sort of file, anyway) is needed (itself in a fixed location) to point
to the port-du-jour.

> if the heartbeat process is running and agrees that the limit for your
> process type hasn't been reached, your process can start.

"The limit for your process type"? That doesn't sound like you're thinking
of an app that should, by default, run as a single instance that "absorbs"
any more that the user triggers by e.g. double-clicking documents, more for
efficiency reasons or to avoid race conditions with its data files than for
any other reason. It sounds more like you're thinking of a situation
involving enforcing policy against users for reasons that have nothing to
do with those users' own wishes, say to limit their resource consumption on
a work computer that isn't theirs.

That's a whole different kettle of fish, but it's a kettle of fish best
handled at the OS level much of the time:

* The resource use at the guy's own cubicle box is his own business. If he
  squanders it and then can't get his work done, he can be let go for poor
  productivity or whatever.

* The resource use on shared machines, e.g. a network server supplying
  services to a whole office block, can be managed by that machine's OS
  having per-user quotas set up, if the users have accounts on it, or by
  the server software enforcing quotas. The latter is similar to how a
  publicly-exposed web service without authentication might prevent one
  user hogging too many resources -- per-connecting-IP resource quotas past
  which it slows down or times out, intentional latency high enough to
  limit the damage a rampaging bot client can do from rapid-fire sequential
  requests but low enough not to nuisance a human user with human reaction
  times, etc.
  Some situations likely in the wild 'net are much less so on the company
  LAN, of course, such as the rampaging bot. And, if something that
  egregious ever does occur, whoever's responsible can be fired.

In a workplace environment, with software customized for that particular
workplace, you can generally go much further in deciding things that users
should and should not do than with software intended for a general audience
including people running it on their own hardware with their own time and
paying their own utility bills.

Even then, it's often better to audit rather than strictly ration use, and
then hold employees accountable for unnecessary and excessive usage based
on the audit reports. Of all the different kinds of bureaucratic red tape
out there, the machine-enforced variety is easily the worst, because it's
typically *impossible* to circumvent without going through the proper
channels, even in direst emergency with some sort of looming deadline and,
with characteristically bad timing, the pointy-haired single point of
failure that holds the needed pad of permission slips home sick. In all
other situations, "contrition is easier than permission" should be a
possible approach, on pain of losing your job if your corner-cutting was
frivolous rather than out of good faith perceived necessity. Though it
certainly should not be the default.

(Of course, because machine-enforced red tape *is* so hard to circumvent,
the bureaucrats *really* love it...)

Another thing to note is that all of the possibly-limited computing
resources -- CPU, disk, memory, bandwidth -- are so cheap these days that a
company can easily afford to have internal servers with 10x or more
capacity than the likely peak load from normal employee use of its
services, such that it would take truly exceptional circumstances (a 10x
bigger than normal demand, or deliberate bad faith or a major malware
infestation) for it to be unable to meet demand. The result is that the
cost in enforcing quotas (or even in auditing usage, possibly) could
actually exceed the benefit (the cost in enforcing has to factor in the
eventuality of someone legitimately needing more than their quota, and the
relevant permission slip being slow or difficult to obtain, with a
deadline; and the cost of both has to factor in the added system complexity
and accompanying bugs; bugs in enforcement are quite likely to result in
people being locked out of the system that are *under* quota, since half of
errors can be expected to be in that direction).

The other limited resource is money, to pay for electricity and (external)
bandwidth whose use may go up. But with efficient hardware an employee
would have to cause very big jumps in server loads to cost noticeable
amounts of marginal hydro-bill dollars, and the firewall can work both ways
to make excessive use of external bandwidth unlikely. Business connections
tend to be non-metered anyway, so while congestion can be a problem overuse
won't directly cost money. (It might indirectly do so, if
revenue-generating public-facing services are knocked out. Those should
probably be on a separate pipe from the one feeding the offices' internet
connectivity, routed differently enough that congesting one won't impair
the other. That's equally important in reverse, so if the web server's
under a DDoS or unusually high legitimate demand it won't cripple the
office workers that need to deal with the problem by cutting them off from
email, Wikipedia, Google, et. al.)

-- 
Hexapodia is the key insight.

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

#21005

On 1/5/2013 12:43 PM, Martin Gregorie wrote:
> However, the automatic cleanup is easy enough to manage from C via the
> atexit() function, which is very to use since you just call atexit() near
> the start of the main() function: once atexit() has registered your exit
> action(s) you get on with whatever the program is meant to do in the
> knowledge that these actions will happen regardless of how the program
> exits (power failures and system crashes excluded).

Unfortunately those may be a pretty big part of the actual
problems encountered in the real world.

We have been talking a lot about killing the process, but the
above two seems much more likely to me.

> It looks as though the nearest we can come to this in Java is via
> try...finally blocks.

To me Runtime addShutdownHook sounds closer in functionality.

> However, I'm wondering if the finally block would always execute, e.g. if
> the try...finally block is in the main() method of a program that exits
> leaving thread(s) running to do the work, does the finally block still
> get still run when the last thread(s) terminates?  I had a fairly cursory
> look at JLS 14.20.1 but it wasn't clear on this point.

http://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html

says:

Note: If the JVM exits while the try or catch code is being executed, 
then the finally block may not execute. Likewise, if the thread 
executing the try or catch code is interrupted or killed, the finally
block may not execute even though the application as a whole continues.

and:

public class ExitFinally {
	public static void main(String[] args) {
		try {
			System.exit(0);
		} finally {
			System.out.println("final");
		}
	}
}

does not print anything.

So I think the answer is NO.

Arne

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

#21009

On 1/3/2013 10:12 AM, Roedy Green wrote:
> On Tue, 01 Jan 2013 12:23:45 -0800, Roedy Green
> <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
>> What is the best way to ensure only a single instance of a Java
>> program is running.
>
> I was expecting this to be a method in some obscure corner of the Java
> API.  I was bracing myself for the usual RTFM (read all docs end to
> end and miss nothing).
>
> The only technique that does not have some major drawback is the UDP
> broadcast, but I don't fully understand it yet.
>
> I have recorded your ideas in my essay at
> http://mindprod.com/jgloss/singleinstance.html

<quote>
Test for the presence of a busy.marker file. If one exists, abort. If 
not create one. The test and create can be in the bat file that triggers 
the app or in the app itself
</quote>

Who can see a concurrency problem in that logic?

<quote>
// if we are seeing our own packet, do nothing
                 if ( theirTime == myTime )
                     {
</quote>

Who can see a concurrency problem in that logic?

<quote>
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 );
</quote>

who thinks this conflicts with the Java docs for addShutdownHook
that states:

"Attempts to use other thread-based services such as the AWT 
event-dispatch thread, for example, may lead to deadlocks."

Arne

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

#21010

On 1/5/2013 7:10 PM, Arne Vajhøj wrote:
> On 1/3/2013 10:12 AM, Roedy Green wrote:
> <quote>
> // if we are seeing our own packet, do nothing
>                  if ( theirTime == myTime )
>                      {
> </quote>
>
> Who can see a concurrency problem in that logic?

The risk is, that in Windows anyway, where the system clock granularity 
is 17ms it is possible to start two copies of a program with a batch 
file and have them both have the same start time.  The risk of doing 
that by hand (which is what I really want to protect against) is, I 
think, infinitesimal.

> <quote>
> 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 );
> </quote>
>
> who thinks this conflicts with the Java docs for addShutdownHook
> that states:
>
> "Attempts to use other thread-based services such as the AWT
> event-dispatch thread, for example, may lead to deadlocks."
>
> Arne

Bad choice of names for my method.  It did seem logical when I thought 
it up though.  It was not my intent however to have this method called 
from Runtime.shutdownHook().  I don't think I knew this method existed.

-- 

Knute Johnson

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

#21011

On 1/5/2013 10:49 PM, Knute Johnson wrote:
> On 1/5/2013 7:10 PM, Arne Vajhøj wrote:
>> On 1/3/2013 10:12 AM, Roedy Green wrote:
>> <quote>
>> // if we are seeing our own packet, do nothing
>>                  if ( theirTime == myTime )
>>                      {
>> </quote>
>>
>> Who can see a concurrency problem in that logic?
>
> The risk is, that in Windows anyway, where the system clock granularity
> is 17ms it is possible to start two copies of a program with a batch
> file and have them both have the same start time.  The risk of doing
> that by hand (which is what I really want to protect against) is, I
> think, infinitesimal.

Many concurrency problems are not very likely.

A lot of people initialized a JFrame based GUI on the main
thread for years without problems.

>> <quote>
>> 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 );
>> </quote>
>>
>> who thinks this conflicts with the Java docs for addShutdownHook
>> that states:
>>
>> "Attempts to use other thread-based services such as the AWT
>> event-dispatch thread, for example, may lead to deadlocks."
>
> Bad choice of names for my method.  It did seem logical when I thought
> it up though.  It was not my intent however to have this method called
> from Runtime.shutdownHook().  I don't think I knew this method existed.

Ah.

My mistake.

I assumed based on the name.

Assumptions are the mother of all f......!

Arne

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

#21035

On 1/5/2013 11:09 PM, Arne Vajhøj wrote:
> On 1/5/2013 10:49 PM, Knute Johnson wrote:
>> On 1/5/2013 7:10 PM, Arne Vajhøj wrote:
>>> On 1/3/2013 10:12 AM, Roedy Green wrote:
>>> <quote>
>>> // if we are seeing our own packet, do nothing
>>>                  if ( theirTime == myTime )
>>>                      {
>>> </quote>
>>>
>>> Who can see a concurrency problem in that logic?
>>
>> The risk is, that in Windows anyway, where the system clock granularity
>> is 17ms it is possible to start two copies of a program with a batch
>> file and have them both have the same start time.  The risk of doing
>> that by hand (which is what I really want to protect against) is, I
>> think, infinitesimal.
>
> Many concurrency problems are not very likely.
>
> A lot of people initialized a JFrame based GUI on the main
> thread for years without problems.

And just to be clear: the code may be perfectly fine for your
specific purpose - I am concerned because Roedy is selling it as
a general solution when it do have a concurrency problem.

Arne

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

#21042

Arne Vajhøj wrote:
>> Many concurrency problems are not very likely.

Exactly what makes them so pernicious to fix.

>> A lot of people initialized a JFrame based GUI on the main
>> thread for years without problems.

That kind of thinking in software engineering has actually killed people. 
Horridly and painfully. 

On single-core CPUs, which are no longer so common, threading issues were 
masked. They became evident to the point where Sun had to change the 
instructions not only about initialization but construction, once multi-core 
mobos became common some years ago. They even had to overhaul the entire 
concurrency memory model. So "years without problems" is an utterly specious
argument.

> And just to be clear: the code may be perfectly fine for your
> specific purpose - I am concerned because Roedy is selling it as
> a general solution when it do have a concurrency problem.

It may be fine for your specific purpose, but if it has a concurrency bug 
wired in I would not bet on it. 

The point in software engineering is *not* to design for the "maybe there 
won't be a problem this time" scenario.

-- 
Lew

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

#21100

On 1/6/2013 12:41 PM, Lew wrote:
> Arne Vajhøj wrote:
>>> Many concurrency problems are not very likely.
>
> Exactly what makes them so pernicious to fix.
>
>>> A lot of people initialized a JFrame based GUI on the main
>>> thread for years without problems.
>
> That kind of thinking in software engineering has actually killed people.
> Horridly and painfully.
>
> On single-core CPUs, which are no longer so common, threading issues were
> masked. They became evident to the point where Sun had to change the
> instructions not only about initialization but construction, once multi-core
> mobos became common some years ago. They even had to overhaul the entire
> concurrency memory model. So "years without problems" is an utterly specious
> argument.

I am pretty sure that it will still work if I try now.

But working 1 out 1 does not make the code correct.

Working 1 billion out of 1 billion does not make it correct.

>> And just to be clear: the code may be perfectly fine for your
>> specific purpose - I am concerned because Roedy is selling it as
>> a general solution when it do have a concurrency problem.
>
> It may be fine for your specific purpose, but if it has a concurrency bug
> wired in I would not bet on it.
>
> The point in software engineering is *not* to design for the "maybe there
> won't be a problem this time" scenario.

True.

But I must plead guilty to having written code that were not so good.

Arne

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

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

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

csiph-web