Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > single instance

Reply
Thread Tools

single instance

 
 
Twirlip of the Mists
Guest
Posts: n/a
 
      01-07-2013
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. )

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.
 
Reply With Quote
 
 
 
 
Twirlip of the Mists
Guest
Posts: n/a
 
      01-07-2013
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.
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
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


 
Reply With Quote
 
Twirlip of the Mists
Guest
Posts: n/a
 
      01-07-2013
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 **** 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.
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
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. )


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

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-07-2013
Twirlip of the Mists wrote:
> 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?


Happens all the time.

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


No True Scotsman. Throw away ahead of time all the valid counterexamples.

> 3. Does anyone tend to make OSen (iPhone "OS" again does not count) that


No True Scotsman. Throw away ahead of time all the valid counterexamples.

> *aren't* fairly POSIXy anymore?
>
> 4. And before you bring up some obscure legacy OS on some archaic mainframe


No True Scotsman. Throw away ahead of time all the valid counterexamples.

Java runs today on some of your "archaic" mainframes.

> that some large banking institution in some obscure corner of the world


Large *and* obscure?

--
Lew
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
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


 
Reply With Quote
 
Twirlip of the Mists
Guest
Posts: n/a
 
      01-07-2013
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.
 
Reply With Quote
 
Twirlip of the Mists
Guest
Posts: n/a
 
      01-07-2013
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. )

>
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Custom Taglib problems - instead of a single instance per page, I have a single instance per application. chris brat Java 1 05-10-2006 11:16 AM
Problem when subclass instance changes base class instance variable Gerry Sutton Python 1 04-16-2005 06:06 AM
Accessing an instance via its memory address (instance at ...) Kent Johnson Python 4 11-13-2004 07:42 PM
converting base class instance to derived class instance Sridhar R Python 14 02-10-2004 02:47 PM
Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class. DJ Dev ASP .Net 3 02-08-2004 04:19 PM



Advertisments