GNU bug report logs - #30421
25.3; desktop.el: Steal lock when no living "emacs" process owns it

Previous Next

Full log

Message #23 received at 30421 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pierre Neidhardt <ambrevar <at> gmail.com>
Cc: 30421 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#30421: 25.3;
 desktop.el: Steal lock when no living "emacs" process owns it
Date: Sun, 11 Feb 2018 19:18:01 +0200

> From: Pierre Neidhardt <ambrevar <at> gmail.com>
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>, 30421 <at> debbugs.gnu.org
> Date: Sun, 11 Feb 2018 17:57:29 +0100
> 
> Setting `desktop-load-locked-desktop' works _only if_ I know there is no
> other emacs (daemon or not) owning the lock.  We still have a conflict 
> otherwise.
> 
> Hence my suggested patch.
> 
> It won't work in the scenario Eli mentioned, but I'm not sure how
> relevant that is.  Isn't better than than generating conflict with local
> instance of Emacs?

No, I don't think so.

Why cannot you simply delete the lock file?  After all, a crashing
Emacs should be a somewhat rare phenomenon...

Alternatively, don't read desktop until the first client connects,
i.e. do that in a after-make-frame-functions hook.  Reading desktop in
daemon mode is problematic for other reasons as well: e.g., GUI frames
cannot be created and GUI features cannot be turned on.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.