[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