On Wed, 9 May 2012 17:20:47 -0700 (PDT)
SegundoBob <[email protected]> wrote:
> I assume that if a process terminates without explicitly releasing a lock,
> then the lock remains in effect a least until the system is rebooted. I
> hope, but do not know, that a lock does not persist over a reboot. These
> and many other details which I don't know will determine if file descriptor
> basedfile locking is practical and desirable. I'm sorry I can't be of more
> help.
Good thought, but there are often cases where you *do* want to open the
file twice, and I'm not sure if that could be done with exclusive locks.
The pid scheme isn't being used at the moment either, because I can't
find a cross-platform (or even a platform specific) way to check that
the pid is still a running instance of Leo. Well, you could parse the
output of subprocess.Popen('ps'), but that's klunky.
So currently g.app.db just holds a list of all open files, each Leo
instance adds and removes files from it, and the user's prompted for
confirmation if a file's already on the list - and then prompted to
remove all entries for the file to clean up after an unclean exit.
Probably works well enough, certainly fulfills the need to catch
multiple openings and warn the user about the data loss risk they pose.
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
