From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Laws Newsgroups: gmane.emacs.bugs Subject: bug#19688: [patch] add support for emacs daemon on Windows Date: Mon, 26 Jan 2015 16:40:10 +0900 Message-ID: References: <83h9ver459.fsf@gnu.org> <83d262qdx6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1422258075 9693 80.91.229.3 (26 Jan 2015 07:41:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Jan 2015 07:41:15 +0000 (UTC) Cc: 19688@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 26 08:41:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1YFeIL-0001Pp-5J for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jan 2015 08:41:13 +0100 Original-Received: from localhost ([::1]:40258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFeIK-0003Wd-9B for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jan 2015 02:41:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFeIG-0003WY-KN for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 02:41:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFeIC-0006Jn-IT for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 02:41:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFeIC-0006Jj-EP for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 02:41:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YFeIC-00026x-3n for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 02:41:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark Laws Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Jan 2015 07:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19688 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 19688-submit@debbugs.gnu.org id=B19688.14222580228057 (code B ref 19688); Mon, 26 Jan 2015 07:41:03 +0000 Original-Received: (at 19688) by debbugs.gnu.org; 26 Jan 2015 07:40:22 +0000 Original-Received: from localhost ([127.0.0.1]:56533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFeHV-00025s-2H for submit@debbugs.gnu.org; Mon, 26 Jan 2015 02:40:21 -0500 Original-Received: from mail-ie0-f177.google.com ([209.85.223.177]:37465) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFeHQ-00025Y-EX for 19688@debbugs.gnu.org; Mon, 26 Jan 2015 02:40:17 -0500 Original-Received: by mail-ie0-f177.google.com with SMTP id vy18so7221843iec.8 for <19688@debbugs.gnu.org>; Sun, 25 Jan 2015 23:40:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aMxcS7kflq29cQVGd81A53zP/s8tqTTRX9VBh2pDIRk=; b=WkVl/rZpAl7peBUzbz9aTj83HVste81cF8w0J2bMVpJ98Jy/FTP2FQniV0hincfLA2 J+tJ7zXgZtnREJ/azkeXDQFYoEDRRo3NUtNfjD4fghMolj2dXahOmI7JwcWK7wnwJpk4 wZMKq7637zzvYG9VMlb45SXw+qYMqECP061m11M2X3mh8jwJOYXMBO0U5LaJYbohvGPq 4iBYyRsIEOvXizbWZaxHleZG4N/As3poVmWHfRQsTECUyw/JMrjOYdAsJmUMZt29ma89 wrvUrXnhzQ00hsUGAnqCa5IxiuhYx3FQ47rHp9DjNLGoKaeQ7WsIE8shjhwGMjHkyqP/ mQOQ== X-Gm-Message-State: ALoCoQkoS7ZErCSwfM7PQjppmMjEeEkKI9PM+unIEbHmEEaKwJCqqdWgZsDcCoCEzUvw9eLf6Nki X-Received: by 10.50.112.98 with SMTP id ip2mr14699441igb.15.1422258010477; Sun, 25 Jan 2015 23:40:10 -0800 (PST) Original-Received: by 10.64.155.4 with HTTP; Sun, 25 Jan 2015 23:40:10 -0800 (PST) X-Originating-IP: [119.245.8.208] In-Reply-To: <83d262qdx6.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98750 Archived-At: On Mon, Jan 26, 2015 at 3:00 PM, Eli Zaretskii wrote: > [Please keep the bug address on the CC list, so that this whole > discussion gets archived.] Oops, blindly hit reply last time without noticing where it was going to--sorry about that. >> Date: Mon, 26 Jan 2015 08:16:38 +0900 >> From: Mark Laws >> >> >> +#define W32_EMACS_SERVER_GUID "{0B8E5DCB-D7CF-4423-A9F1-2F6927F0D318}" >> > >> > Where did this GUID come from? >> > >> I generated it myself. > > Is that safe? Do we care whether this GUID is globally unique? Why > exactly do we need it to begin with? It should be safe. On UNIX, Emacs uses a pipe to tell emacsclient when it's done initializing. On Windows, since we don't have fork, the easiest options are either a named event object[1] or specifying that the child process inherit the event handle in CreateProcess. The former is simpler, so I went with it. We could call it "EmacsDaemonEvent" or something instead; it doesn't really matter as long as it's a name nothing else is likely to use. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682396%28v=vs.85%29.aspx >> > Why do we need anything beyond the event handle? Can't it serve >> > double duty as a flag as well? We could use INVALID_HANDLE_VALUE >> > and/or NULL as distinct values with specific meanings. >> >> I've reworked it to use only w32_daemon_event. One minor issue: to >> avoid including any Windows-related headers in lisp.h, the extern >> declaration of w32_daemon_event there is void* instead of HANDLE. I >> doubt the type of HANDLE will ever change, so it shouldn't matter >> much. > > That should be fine, but there's no need to have the handle in lisp.h, > either. We could put it on w32.h, for example, which is already > included by emacs.c and other files. If w32.h doesn't fit the bill, > please try to find some other w32*.h which does. IS_DAEMON is defined in lisp.h, so it seems to make the most sense to put it there rather than having a different IS_DAEMON for Windows in another place. We'd have to #include a w32 header just for IS_DAEMON in a lot more files if we move it to one of them, too. >> >> +#ifndef WINDOWSNT >> >> /* Make sure IS_DAEMON starts up as false. */ >> >> daemon_pipe[1] = 0; >> >> +#endif >> > >> > You should do a similar initialization on WINDOWSNT, to avoid using >> > the value that was initialized when Emacs was dumped. >> >> I'm not sure I understand. Do you mean for w32_daemon_event? If so, it >> should already always be zero when Emacs starts up. > > It might not be zero. Recall that Emacs is run during the build > process, when it executes some code, and then "dumps itself", which > involves writing portions of its memory to a disk file that thereafter > becomes the emacs.exe you run normally. If, for some reason, > w32_daemon_event is initialized in this first instance, it will not be > zero in the dumped image. > > So we always re-initialize such variables explicitly, instead of > relying on the linker initializations. You can see that in the > sources, and that is also the reason why the Posix code initializes > daemon_pipe[1]. OK, fixed. >> > Also, the call to daemon_check_preconditions should be outside of the >> > #ifdef, as it is used on all platforms. >> >> daemon_check_preconditions already gets called for both WINDOWSNT and >> !WINDOWSNT (see the #else). If we move it outside the #ifdef to >> eliminate having to mention it for both cases, then "nfd" and "err" >> will also have to be outside the ifdef in order to be compatible with >> strict pre-C99 compilers that only accept variable declarations at the >> beginning of blocks. > > C99 compliant compiler is a prerequisite in the development version of > Emacs, so this problem doesn't exist. Fixed. I'll attach another patch when we figure out what to do about the remaining issues. -- |v\ /\ |\ |< |_ /\ \^| //