[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Detecting running application

From: Richard Frith-Macdonald
Subject: Re: Detecting running application
Date: Thu, 11 May 2006 15:28:30 +0100

On 11 May 2006, at 15:05, Chris B. Vetter wrote:

On 5/11/06, Richard Frith-Macdonald <address@hidden> wrote:
Oh sure ... I thought you meant using the DO name service code (as
you mentioned using gdomap earlier) not just sending messages around.

I mentioned gdomap WRT to the launch of applications. I _thought_
gdomap was used to keep a registration of running applications back in
the old days.

Yes ... still is for any connections which are not host-local.

In the meantime you could, as a proof of concept, use the last path
component of the bundle path rather than the full thing.

I used the full path name as returned by NSBundle-bundlePath as well
as an imaginary name (ok, ok, "foobar") as well as just the bundle
name (w/o a path). Neither got registered.  I also checked with
--GNU-Debug=NSMessagePort and noticed that the created port was always
registered with the application names.
That is /tmp/GNUstepSecure<id>/NSMessagePort/names/<app name> was
referring to .../ports/<pid>.x=

All applications create a DO port and register their name to it ... that has nothing to do with the separately created port you use for your bundle hacks.

Actually I would have thought it made sense to have it be an app/
daemon rather than a loadable bundle.

Yes, but that was just an example.

Well, I *sort* of see ... but it looks to me like the sort of
functionality you are describing would make more sense as apps or
daemons or as functionality provided as services than in bundles.

But I never said I was working on a project that made any sense ;-)

What about a simple background app built solely to run the
bundles ... then you never need to worry about the bundles being
loaded in multiple apps since there is only a single app loading them

However, the example (displaying images in background) as a bundle
could be used by a desktop manager as a 'plugin' -- no need to launch
another application/daemon then.

OK ... for that case (a code bundle which wants to ensure that no other copies of the same bundle are running for the same user on the same machine), I think it's pretty simple.

The principal class of the bundle has an init method which ...

1. Creates an NSMessagePort instance
2. calls [NSMessagePortNameServer-registerPort:forname:] useing the newly created port and a unique identifier for the bundle
If the registration attempt returns YES ... it goes on as normal
If the registration attempt returns NO ... it deallocates the receiver and returns nil

Of course you could use any other synchronisation mechanism, but NSMessagePortNameServer is convenient.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]