* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
[not found] <mailman.190526.1391788637.10747.emacs-diffs@gnu.org>
@ 2014-02-07 16:20 ` Eli Zaretskii
2014-02-07 19:42 ` Juri Linkov
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2014-02-07 16:20 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
> --- a/lisp/ChangeLog 2014-02-07 07:51:56 +0000
> +++ b/lisp/ChangeLog 2014-02-07 07:58:10 +0000
> @@ -1,5 +1,10 @@
> 2014-02-07 Juri Linkov <juri@jurta.org>
>
> + * desktop.el (desktop-read): Claim the lock when the owner is not
> + the current process. (Bug#16157)
> +
What happens if an Emacs session that locked the desktop file is still
alive?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-07 16:20 ` [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process Eli Zaretskii
@ 2014-02-07 19:42 ` Juri Linkov
2014-02-07 20:25 ` Juanma Barranquero
2014-02-08 7:52 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Juri Linkov @ 2014-02-07 19:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> + * desktop.el (desktop-read): Claim the lock when the owner is not
>> + the current process. (Bug#16157)
>
> What happens if an Emacs session that locked the desktop file is still
> alive?
The one that comes last wins. The last session will do auto-saving,
the previous won't. At least, there should be no conflict of both sessions
trying to auto-save to the same file, because auto-saving checks the ownership.
The conflict might occur when during exiting both sessions will try writing
to the same file. I see nothing in `desktop-kill' that would prevent saving
to a non-locked desktop, except the question "Save desktop?"
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-07 19:42 ` Juri Linkov
@ 2014-02-07 20:25 ` Juanma Barranquero
2014-02-08 10:11 ` Juri Linkov
2014-02-08 7:52 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2014-02-07 20:25 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Emacs developers
On Fri, Feb 7, 2014 at 8:42 PM, Juri Linkov <juri@jurta.org> wrote:
> The one that comes last wins.
Why is that better? I often start a second Emacs instance, and in
almost all cases I want the first one to keep the desktop.
What problem is that trying to fix, and why isn't
desktop-load-locked-desktop enough?
J
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-07 19:42 ` Juri Linkov
2014-02-07 20:25 ` Juanma Barranquero
@ 2014-02-08 7:52 ` Eli Zaretskii
2014-02-08 10:14 ` Juri Linkov
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2014-02-08 7:52 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2014 21:42:00 +0200
>
> >> + * desktop.el (desktop-read): Claim the lock when the owner is not
> >> + the current process. (Bug#16157)
> >
> > What happens if an Emacs session that locked the desktop file is still
> > alive?
>
> The one that comes last wins. The last session will do auto-saving,
> the previous won't. At least, there should be no conflict of both sessions
> trying to auto-save to the same file, because auto-saving checks the ownership.
> The conflict might occur when during exiting both sessions will try writing
> to the same file. I see nothing in `desktop-kill' that would prevent saving
> to a non-locked desktop, except the question "Save desktop?"
That's not what I see today, I think. When I need to test something
in a fresh session, I sometimes by mistake invoke "emacs" instead of
"emacs -Q", which reads my ~/.emacs and activates desktop saving. The
main Emacs session is alive, of course. Then, when I exit, I'm asked
whether to save desktop and given the opportunity to say NO, because I
certainly don't want my main desktop file to be overwritten by this
mistaken session. I'm not sure this change doesn't eliminate this
useful capability.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-07 20:25 ` Juanma Barranquero
@ 2014-02-08 10:11 ` Juri Linkov
2014-02-08 10:21 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Juri Linkov @ 2014-02-08 10:11 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, Emacs developers
>> The one that comes last wins.
>
> Why is that better? I often start a second Emacs instance, and in
> almost all cases I want the first one to keep the desktop.
>
> What problem is that trying to fix, and why isn't
> desktop-load-locked-desktop enough?
The problem was that when a session crashes, all subsequent sessions
can't auto-save the desktop since they didn't take the lock
from the crashed session.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 7:52 ` Eli Zaretskii
@ 2014-02-08 10:14 ` Juri Linkov
2014-02-08 10:47 ` David Kastrup
2014-02-08 10:52 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Juri Linkov @ 2014-02-08 10:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> The one that comes last wins. The last session will do auto-saving,
>> the previous won't. At least, there should be no conflict of both sessions
>> trying to auto-save to the same file, because auto-saving checks the ownership.
>> The conflict might occur when during exiting both sessions will try writing
>> to the same file. I see nothing in `desktop-kill' that would prevent saving
>> to a non-locked desktop, except the question "Save desktop?"
>
> That's not what I see today, I think. When I need to test something
> in a fresh session, I sometimes by mistake invoke "emacs" instead of
> "emacs -Q", which reads my ~/.emacs and activates desktop saving. The
> main Emacs session is alive, of course. Then, when I exit, I'm asked
> whether to save desktop and given the opportunity to say NO,
When you invoke "emacs" instead of "emacs -Q" by mistake,
it warns you about the mistake by asking
"Warning: desktop file appears to be in use by PID %s.
Using it may cause conflicts. Use it anyway? "
so you could just say NO.
> because I certainly don't want my main desktop file to be overwritten
> by this mistaken session. I'm not sure this change doesn't eliminate
> this useful capability.
Even when you answer YES, and a new session will auto-save the desktop,
you still can save the final version of the desktop from the first session
if you exit it later than the auto-saving session, so it will overwrite
the desktop from the latest exited session.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:11 ` Juri Linkov
@ 2014-02-08 10:21 ` Juanma Barranquero
2014-02-08 10:35 ` Juri Linkov
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2014-02-08 10:21 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Emacs developers
On Sat, Feb 8, 2014 at 11:11 AM, Juri Linkov <juri@jurta.org> wrote:
> The problem was that when a session crashes, all subsequent sessions
> can't auto-save the desktop since they didn't take the lock
> from the crashed session.
Surely I'm missing something, but what good is the lock if subsequent
sessions can steal it even if the corresponding Emacs is still
running?
J
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:21 ` Juanma Barranquero
@ 2014-02-08 10:35 ` Juri Linkov
2014-02-08 10:42 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Juri Linkov @ 2014-02-08 10:35 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, Emacs developers
>> The problem was that when a session crashes, all subsequent sessions
>> can't auto-save the desktop since they didn't take the lock
>> from the crashed session.
>
> Surely I'm missing something, but what good is the lock if subsequent
> sessions can steal it even if the corresponding Emacs is still
> running?
Maybe we need a separate question in addition to the existing question
1. "Warning: desktop file appears to be in use by PID %s.
Using it may cause conflicts. Use it anyway? "
something like
2. "Claim the lock from PID %s to take the ownership of the desktop file? "
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:35 ` Juri Linkov
@ 2014-02-08 10:42 ` Juanma Barranquero
2014-02-08 19:32 ` Juri Linkov
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2014-02-08 10:42 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Emacs developers
On Sat, Feb 8, 2014 at 11:35 AM, Juri Linkov <juri@jurta.org> wrote:
> Maybe we need a separate question in addition to the existing question
>
> 1. "Warning: desktop file appears to be in use by PID %s.
> Using it may cause conflicts. Use it anyway? "
>
> something like
>
> 2. "Claim the lock from PID %s to take the ownership of the desktop file? "
Something like that, but it needs to be possible to configure it to
not ask/not claim, if that's what the user wants.
As an example, in my .emacs, I set desktop-load-locked-desktop to nil,
and then I add code to desktop-not-loaded-hook that only steals the
lock if the PID of the old lock does not match a running Emacs
instance; if the old Emacs is still running I only throw a warning.
J
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:14 ` Juri Linkov
@ 2014-02-08 10:47 ` David Kastrup
2014-02-08 10:52 ` Eli Zaretskii
1 sibling, 0 replies; 16+ messages in thread
From: David Kastrup @ 2014-02-08 10:47 UTC (permalink / raw)
To: emacs-devel
Juri Linkov <juri@jurta.org> writes:
>>> The one that comes last wins. The last session will do auto-saving,
>>> the previous won't. At least, there should be no conflict of both sessions
>>> trying to auto-save to the same file, because auto-saving checks the ownership.
>>> The conflict might occur when during exiting both sessions will try writing
>>> to the same file. I see nothing in `desktop-kill' that would prevent saving
>>> to a non-locked desktop, except the question "Save desktop?"
>>
>> That's not what I see today, I think. When I need to test something
>> in a fresh session, I sometimes by mistake invoke "emacs" instead of
>> "emacs -Q", which reads my ~/.emacs and activates desktop saving. The
>> main Emacs session is alive, of course. Then, when I exit, I'm asked
>> whether to save desktop and given the opportunity to say NO,
>
> When you invoke "emacs" instead of "emacs -Q" by mistake,
> it warns you about the mistake by asking
>
> "Warning: desktop file appears to be in use by PID %s.
> Using it may cause conflicts. Use it anyway? "
>
> so you could just say NO.
It will still want to _save_ the desktop even if you answer No to
loading it.
--
David Kastrup
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:14 ` Juri Linkov
2014-02-08 10:47 ` David Kastrup
@ 2014-02-08 10:52 ` Eli Zaretskii
2014-02-08 11:16 ` Andreas Schwab
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2014-02-08 10:52 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Feb 2014 12:14:44 +0200
>
> >> The one that comes last wins. The last session will do auto-saving,
> >> the previous won't. At least, there should be no conflict of both sessions
> >> trying to auto-save to the same file, because auto-saving checks the ownership.
> >> The conflict might occur when during exiting both sessions will try writing
> >> to the same file. I see nothing in `desktop-kill' that would prevent saving
> >> to a non-locked desktop, except the question "Save desktop?"
> >
> > That's not what I see today, I think. When I need to test something
> > in a fresh session, I sometimes by mistake invoke "emacs" instead of
> > "emacs -Q", which reads my ~/.emacs and activates desktop saving. The
> > main Emacs session is alive, of course. Then, when I exit, I'm asked
> > whether to save desktop and given the opportunity to say NO,
>
> When you invoke "emacs" instead of "emacs -Q" by mistake,
> it warns you about the mistake by asking
>
> "Warning: desktop file appears to be in use by PID %s.
> Using it may cause conflicts. Use it anyway? "
Not if I load from a different desktop file.
> > because I certainly don't want my main desktop file to be overwritten
> > by this mistaken session. I'm not sure this change doesn't eliminate
> > this useful capability.
>
> Even when you answer YES, and a new session will auto-save the desktop,
> you still can save the final version of the desktop from the first session
> if you exit it later than the auto-saving session, so it will overwrite
> the desktop from the latest exited session.
Isn't it safer to see of the PID that locked the desktop file still
runs, and if so, ask for permission?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:52 ` Eli Zaretskii
@ 2014-02-08 11:16 ` Andreas Schwab
2014-02-08 14:22 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Andreas Schwab @ 2014-02-08 11:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juri Linkov, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Isn't it safer to see of the PID that locked the desktop file still
> runs, and if so, ask for permission?
What if the other instance runs on a different host?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 11:16 ` Andreas Schwab
@ 2014-02-08 14:22 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2014-02-08 14:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: juri, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Juri Linkov <juri@jurta.org>, emacs-devel@gnu.org
> Date: Sat, 08 Feb 2014 12:16:15 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Isn't it safer to see of the PID that locked the desktop file still
> > runs, and if so, ask for permission?
>
> What if the other instance runs on a different host?
What if the PID is reused?
Yes, we could cater to all these, if we want. But not using even the
PID seems too sloppy, IMO.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 10:42 ` Juanma Barranquero
@ 2014-02-08 19:32 ` Juri Linkov
2014-02-08 20:29 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Juri Linkov @ 2014-02-08 19:32 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, Emacs developers
>> Maybe we need a separate question in addition to the existing question
>>
>> 1. "Warning: desktop file appears to be in use by PID %s.
>> Using it may cause conflicts. Use it anyway? "
>>
>> something like
>>
>> 2. "Claim the lock from PID %s to take the ownership of the desktop file? "
>
> Something like that, but it needs to be possible to configure it to
> not ask/not claim, if that's what the user wants.
Then instead of asking a question we could add two new values
to `desktop-load-locked-desktop'
ask-and-lock -- ask the user and lock the desktop.
load-and-lock -- load and lock anyway.
with the default to `ask-and-lock'. Whereas the existing
t -- load anyway.
ask -- ask the user.
will load without locking.
> As an example, in my .emacs, I set desktop-load-locked-desktop to nil,
> and then I add code to desktop-not-loaded-hook that only steals the
> lock if the PID of the old lock does not match a running Emacs
> instance; if the old Emacs is still running I only throw a warning.
I guess your code to detect a running Emacs instance is not too reliable
to include to desktop.el?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 19:32 ` Juri Linkov
@ 2014-02-08 20:29 ` Juanma Barranquero
2014-02-08 21:08 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2014-02-08 20:29 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Emacs developers
On Sat, Feb 8, 2014 at 8:32 PM, Juri Linkov <juri@jurta.org> wrote:
> Then instead of asking a question we could add two new values
> to `desktop-load-locked-desktop'
>
> ask-and-lock -- ask the user and lock the desktop.
> load-and-lock -- load and lock anyway.
>
> with the default to `ask-and-lock'. Whereas the existing
>
> t -- load anyway.
> ask -- ask the user.
>
> will load without locking.
Seems OK.
> I guess your code to detect a running Emacs instance is not too reliable
> to include to desktop.el?
Alas, no. It's Windows-specific, and depends on the fact that I know I
won't have a lock from a remote Emacs instance, and that all my
instances are launched from executables called emacs.exe.
J
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.
2014-02-08 20:29 ` Juanma Barranquero
@ 2014-02-08 21:08 ` Juanma Barranquero
0 siblings, 0 replies; 16+ messages in thread
From: Juanma Barranquero @ 2014-02-08 21:08 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Emacs developers
On Sat, Feb 8, 2014 at 9:29 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> Alas, no. It's Windows-specific, and depends on the fact that I know I
> won't have a lock from a remote Emacs instance, and that all my
> instances are launched from executables called emacs.exe.
Well, not really Windows-specific, though it does depend on the other
two conditions. Basically I'm doing something like this:
(setq desktop-load-locked-desktop nil)
(add-hook 'desktop-not-loaded-hook
(lambda ()
(let ((owner (desktop-owner))
(desktop-load-locked-desktop t))
(cond ((= owner (emacs-pid))
(desktop-read))
((let ((command (cdr (assq 'comm
(process-attributes owner))))
(case-fold-search t))
(and command
(string-match-p
"^emacs\\(?:-[0-9.]+\\)?\\(?:\\.exe\\)$" command)))
(warn "Locked by Emacs (%s)" owner)
(desktop-save-mode -1))
((ignore-errors (delete-file (desktop-full-lock-name)) t)
(warn "Stale lock by Emacs (%s) deleted" owner)
(desktop-read))
(t
(warn "Could not delete stale lock by Emacs (%s)" owner)
(desktop-save-mode -1))))))
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-02-08 21:08 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.190526.1391788637.10747.emacs-diffs@gnu.org>
2014-02-07 16:20 ` [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process Eli Zaretskii
2014-02-07 19:42 ` Juri Linkov
2014-02-07 20:25 ` Juanma Barranquero
2014-02-08 10:11 ` Juri Linkov
2014-02-08 10:21 ` Juanma Barranquero
2014-02-08 10:35 ` Juri Linkov
2014-02-08 10:42 ` Juanma Barranquero
2014-02-08 19:32 ` Juri Linkov
2014-02-08 20:29 ` Juanma Barranquero
2014-02-08 21:08 ` Juanma Barranquero
2014-02-08 7:52 ` Eli Zaretskii
2014-02-08 10:14 ` Juri Linkov
2014-02-08 10:47 ` David Kastrup
2014-02-08 10:52 ` Eli Zaretskii
2014-02-08 11:16 ` Andreas Schwab
2014-02-08 14:22 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.