moreThanOneInstanceAllowed question


#1

I need to throw up a dialog box if my app catches another juce app with a particular name running when it starts up.

On windows, that wasn’t hard, I copied the lock code from juce into my moreThanOnceInstanceAllowed() routine:

InterProcessLock* appLock = 0;
appLock = new InterProcessLock ("juceAppLock_" + theOtherAppName);
if (! appLock->enter(0)){
    //other app found. Put up dialog
   }

This works on windows, but the same code on the mac fails. The Lock seems to work, and my dialog is never seen. What’s the correct way to go about doing this on the mac?


#2

There was an interprocesslock problem that I just fixed last week, so get the tip.

And remember that by default the mac prevents more than one instance of an app from even launching, so that might explain it.


#3

I knew that the MacOS prevents multiple instances from running. What I’m really trying to do is to find out if my (just launched) process is going to be killed because it’s a second instance.

On the Mac, it appears that the interprocesslock wasn’t what was preventing the second process from launching as it did on the PC, but clearly something else was.

Thanks for the tip about the bug fix. I’ll synch up.


#4

I synched to the svn tip. Still no luck determining if the named process is running.

When I step into appLock->enter(0), the first call to

fcntl (filedesc, F_SETLK, &fl);

returns 0, so the enter() returns true. enter() returns false on windows in the same code.

Is this the expected behavior if a similarly named app is running on the Mac?


#5

More information…

The 1.45 mac code does work if I launch a second instance of the same application. I’m trying to test to see if an application who’s name is set in the InterProcessLock constructor is running.

Could it be that InterProcessLock() isn’t using the lock string passed in the constructor to do its comparisions?


#6

Oh, I see. It shouldn’t matter about the process - you can see that it uses a shared file which gets created in juce_posix_SharedCode.cpp. The filename should be based on whatever string you use.


#7

Ah. I see what’s going on now. On the mac the lock file is in
~/Library/Cache/App1/juceAppLock_App1

When the new process checks for the lock file, it looks in
~/Library/Cache/App2/juceAppLock_App1

Obviously, that file is only locked if the full path matches, not just the application name.

I’ll need to be a little trickier to get the lock file status.


#8

Ah, yes, the temp folder on the mac is application-specific. I’ve checked-in a tweaked version now that should work better.