From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] A myriad of interrelated daemon-mode startup bugs Date: Tue, 13 Nov 2012 14:41:57 -0500 Message-ID: References: <87haotpg6g.fsf@spindle.srvr.nix> <87zk2lny4o.fsf@spindle.srvr.nix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352835749 18537 80.91.229.3 (13 Nov 2012 19:42:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2012 19:42:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nix Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 13 20:42:38 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYMNa-0003BQ-3l for ged-emacs-devel@m.gmane.org; Tue, 13 Nov 2012 20:42:38 +0100 Original-Received: from localhost ([::1]:59275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYMNQ-0006ad-HQ for ged-emacs-devel@m.gmane.org; Tue, 13 Nov 2012 14:42:28 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYMNL-0006Sk-Ap for emacs-devel@gnu.org; Tue, 13 Nov 2012 14:42:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYMNI-0002wC-7i for emacs-devel@gnu.org; Tue, 13 Nov 2012 14:42:23 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:33964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYMNG-0002va-Vh for emacs-devel@gnu.org; Tue, 13 Nov 2012 14:42:20 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id qADJfww7026637; Tue, 13 Nov 2012 14:41:58 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id E1AFDB4278; Tue, 13 Nov 2012 14:41:57 -0500 (EST) In-Reply-To: <87zk2lny4o.fsf@spindle.srvr.nix> (nix@esperi.org.uk's message of "Tue, 13 Nov 2012 18:41:59 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4401=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4401> : streams <857702> : uri <1267233> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154855 Archived-At: >>> - (cl-letf (((default-file-modes) ?\700)) (make-directory dir t)) >>> + (make-directory dir t ?\700) >> The cl-letf ends up doing the exact same thing, via dynamic scoping >> (note how it's not a simple `let' and it doesn't bind a variable but >> a "place"). > Ah! Mind you, there's not much hint in the docs for cl-letf that it's > dynamically bound... lexical-scoping for non-variables is pretty hard to even define, so if you think hard about it (and follow the consequence of "Each PLACE is set to the corresponding VALUE, then the BODY forms are executed. On exit, the PLACEs are set back to their original values") you'll see it can only be dynamically scoped. >> I'm not completely opposed to adding a "modes" argument to >> make-directory, but I'm not sure it's worth the trouble. > It's a potential security hole to make directories with the wrong mode, > so it seems like a good idea. (Sure, you can bind `default-file-modes', > but could you really call the code above particularly clear?) I'm a firm believer in explicit arguments and lexical-scoping, but it has to be weighed against the cost of change. As written above, I'm not sure which side wins here. >> (unwind-protect >> (server-start) >> (if server-process >> (daemon-initialized) >> (if (stringp dn) >> ... > That works, but it throws away the error message. If `server-start' > raised an error, you want to show it to the user before you die. No, unwind-protect doesn't catch the error and doesn't silence it either. >>> + ;; We must pretend to be noninteractive at this point to tell >>> + ;; kill-emacs-hook functions that read input if interactive >>> + ;; not to do so, since reads from stdin are shared with the >>> + ;; parent. >>> + (let ((noninteractive t)) >>> + (kill-emacs 1))))) >> Actually, `noninteractive' can sometimes interact with the user via >> stdin/stdout. > OK, so that ugly kludge is presumably unnecessary? Phew. No, but when the kill-emacs-hook code uses `noninteractive' it may do it to check something else than that you intended. >> How 'bout having a Lisp-exported variable that controls whether to call >> kill-emacs here? Then server.el could set this var (after successfully >> starting the daemon) to prevent exit. > Instead of daemon-initialized? The worry there is that server-start can > be called from places *other* than daemonization, and it seems like a > layering violation to have it saying 'yeah, you can exit now' if it was > called from somewhere else. Hmm... you mean that my Emacs wouldn't die any more upon C-x C-c because my .emacs calls server-start. Right. Hmm... >> Also, maybe the right way to solve this is to think harder about what >> noninteractive means and how to split it into several variables. >> E.g. one meaning is "no input events", another is "I/O is via >> stdin/stdout", and another we need is "there's no I/O available right >> now". > That's exactly what I was thinking while I got repeatedly confused over > just what 'noninteractive' meant right now. At the moment, it seems to > be used to mean whichever of the above is most convenient at the time :) Yes, it's pretty messy. The original meaning was "running in -batch mode", i.e. with I/O via the special terminal that's bound to stdin/stdout. So maybe we should just add another var for "no I/O available" (e.g. after closing all terminals, either about to exit or waiting for new emacsclient connections). Or rather a predicate (which just checks the list of open terminals and decides whether there's one that can offer I/O). Stefan