[scribus] Multiple instances of Scribus

Craig Ringer craig at postnewspapers.com.au
Wed Apr 30 08:35:54 CEST 2008


John Brown wrote:

>> That's a lot of platform specific messing around, though, for a pretty 
>> trivial feature. Personally I wouldn't bother.
>>
> 
> A simple way would be to create a lock file the sole purpose of which
> is to indicate that Scribus has already opened the file.

Lock files are IMO about the *worst* way of doing it.

If Scribus crashes, the lock file may not be cleaned up
(depending on whether or not the crash handler can run successfully).

This is OK on non-networked storage, because we can store the process
ID in the lockfile and see if there's a Scribus process with that ID
running. If there isn't the lockfile is clearly stale and can be removed.

On network storage, however, we cannot test to see if the lockfile
creator is still running. In fact, even if the lockfile creator is still 
running, it might no longer have access to the network volume. That 
leaves the poor user to deal with the mess.

Avoid lock files at all costs. If locking is required, it's much better 
to use the advisory or mandatory locking mechanisms provided by the 
operating system.

QuarkXPress has an interesting spin on lock files. It creates a 
temporary file in the same directory as the original file, and holds an 
exclusive access file handle open on the temporary. Nobody else can 
create a temporary with the same name, so the file is "locked" that way. 
If the Quark user loses their connection the file handle on the 
temporary is closed and another instance can open it and offer to 
recover the unsaved work, or can just delete and recreate it when 
opening the file again.

Scribus doesn't need such temporaries, so it makes more sense to just 
lock the original file if that's desired.

Also: Libraries and such should not be locked, as ideally it should be 
possible to share them.

--
Craig Ringer




More information about the scribus mailing list