v1.7 - Duplicate Instance Detection Fails

Bug #501644 reported by aidave
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Kabikaboo
Confirmed
Medium
Unassigned

Bug Description

In 1.6 this worked.
It should be a simple fix for Linux.

Modify the search function in kabikaboo.py ~ line 2938:

# check for duplicate instance of kabikaboo
    def check_for_duplicate_instance(self):
        result = False
        # WARNING: LINUX ONLY CODE
        output = commands.getoutput('ps -ax')
        # check for 2 or more regular instances
        if output.count('python kabikaboo.py') >= 2:
            result = True
        # check for instance and development instance
        if output.count('python kabikaboo.py') >= 1 and output.count('python -W ignore::DeprecationWarning kabikaboo.py') >= 1:
            result = True
        if result:
            print 'Duplicate instance of Kabikaboo already running.'
            print 'Will not open last file in this case.'
            print 'Starting with new document.'
            self.file.working_file = ''
        return result

Windows will need different code to do this.

aidave (aidave)
Changed in kabikaboo:
importance: Undecided → Medium
milestone: none → 1.8
Revision history for this message
S (supertanker) wrote :

The 'normal' linux-ey way to do it is to write a PID file with the id of the Kabikaboo process inside it. The program then checks to see if that particular process is running and errors out if it is; if not, it replaces the old pid inside the file with the new pid. Makes cleanups a little less 'meh' with lockfiles and makes it easier to maintain if the command line suddenly changes and so the output of ps -ax isn't what is expected. (Sorry if that's incoherant, no time to wake up yet).

From what I can tell, the Windows alternative is either A. A lockfile or B. something called a 'mutex', which looks like some sort of process-unique identifier that other processes can examine. Lookie here: http://code.activestate.com/recipes/474070/

Of course, with some 'if win32:' ... 'else:' code... in between...
No time to work until this evening, but might get around to prodding around

Revision history for this message
Jeremy Bícha (jbicha) wrote :

Well, for one thing , the application is now just "kabikaboo" not "python kabikaboo.py" . Check your top or System Monitor or whichever to verify. (And then there's the other kabikaboo-dev which is really just local kabikaboo which probably should be done a little differently, maybe with a command line option)

aidave (aidave)
Changed in kabikaboo:
status: New → Confirmed
Revision history for this message
S (supertanker) wrote :

Well, after thinking about this a bit and trying a few ideas last night, I realized something: right now, Kabikaboo detects if another instance of itself is running to prevent overwriting a single file, since Kabikaboo can currently only open one file at a time. If this is the case, what would be the advantages and disadvantages of having Kabikaboo detect if a file is currently in use (With a Word-style 'lock' file, perhaps?) instead of detecting if another version is running? Then, it would be possible to have two instances running on different files. (*And*, this would not require Linux/Win specific code--just code to detect if the directory where a file resides--or possibly the user's .kabikaboo or even ~ directory--has a filename.doc.tmp file to see if it is currently in use. Kabikaboo would create the (empty) file on opening filename.doc and remove the temporary lockfile on close (checking to make sure it can write to the lockfile, of course--maybe have a fallback system: first try the directory where the document is, then try ~, then give an error?)

Just spewing some thoughts. The current system doesn't--or didn't--allow two instances working on *different* files. Also, if we wanted full duplicate instance detection, it'd be necessary to kill the second instance of Kabikaboo completely upon detection of the first instance, instead of allowing it to load with a blank template (and that second instance could be used to open the file being used by the first instance...)

In fact, now that I think about it, it'd be necessary to check if the file was in use through the Open dialog, too, instead of just on autoload. Maybe only allowing a single instance *would* be easier...a single .pid file for Linux and a mutex for Windows.

Thoughts?

Revision history for this message
aidave (aidave) wrote :

I do want to be able to run multiple instances because I can have multiple .kaboo documents going at any one time.

Tracking which files are open is an idea worth exploring. The main issue is with unexpected crashes, and making sure the user isn't stopped from opening a file, when the program thinks its open but it isnt. So if I'm working on file X and my computer reboots, then we would have to detect that and deal with that. I'm not sure if this is 100% possible... maybe bring up a dialog on startup asking user to allow them to open that file anyways?

However I think we may be shooting our selves in the foot if we try to stop users from opening the same file twice. It is a nice feature to have, but, the user may have a bizarre reason to do so: they might want to copy that file or some such. You and I would never do that but some one might because they are used to other programs allowing this... (I'm thinking abiword)

I think the best behaviour may be:
- When Kabikaboo starts, check if its the only running instance:
-- If it is, open the last file (if set)
-- If it is not, start a new file
- When a user opens a file, check to see if another running instance has that file open:
-- If it is already open, pop a warning dialog to the user, asking if they really want to continue

cheers
dave

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.