From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19688: [patch] add support for emacs daemon on Windows Date: Sat, 14 Feb 2015 14:10:28 +0200 Message-ID: <8361b4y9qj.fsf@gnu.org> References: <83h9ver459.fsf@gnu.org> <83d262qdx6.fsf@gnu.org> <54C62B6C.3050608@dancol.org> <834mr8n5or.fsf@gnu.org> <83pp9e42n8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423915891 22754 80.91.229.3 (14 Feb 2015 12:11:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 12:11:31 +0000 (UTC) Cc: 19688@debbugs.gnu.org To: mdl@60hz.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 14 13:11:20 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 1YMbZ9-0004We-88 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Feb 2015 13:11:19 +0100 Original-Received: from localhost ([::1]:59520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMbZ8-0002Zf-45 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Feb 2015 07:11:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMbYz-0002ZW-0R for bug-gnu-emacs@gnu.org; Sat, 14 Feb 2015 07:11:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMbYt-0002IG-6C for bug-gnu-emacs@gnu.org; Sat, 14 Feb 2015 07:11:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMbYt-0002I3-2y for bug-gnu-emacs@gnu.org; Sat, 14 Feb 2015 07:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YMbYs-0004BF-HQ for bug-gnu-emacs@gnu.org; Sat, 14 Feb 2015 07:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Feb 2015 12:11:02 +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.142391584016041 (code B ref 19688); Sat, 14 Feb 2015 12:11:02 +0000 Original-Received: (at 19688) by debbugs.gnu.org; 14 Feb 2015 12:10:40 +0000 Original-Received: from localhost ([127.0.0.1]:42754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMbYV-0004Ae-GP for submit@debbugs.gnu.org; Sat, 14 Feb 2015 07:10:39 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:63224) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMbYQ-0004AJ-Py for 19688@debbugs.gnu.org; Sat, 14 Feb 2015 07:10:36 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NJR00900FU0BZ00@a-mtaout21.012.net.il> for 19688@debbugs.gnu.org; Sat, 14 Feb 2015 14:10:28 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJR009GDGHF9F70@a-mtaout21.012.net.il>; Sat, 14 Feb 2015 14:10:28 +0200 (IST) In-reply-to: <83pp9e42n8.fsf@gnu.org> X-012-Sender: halo1@inter.net.il 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:99372 Archived-At: > Date: Fri, 13 Feb 2015 10:49:31 +0200 > From: Eli Zaretskii > Cc: 19688@debbugs.gnu.org > > > Date: Fri, 13 Feb 2015 09:07:04 +0900 > > From: Mark Laws > > Cc: Daniel Colascione , 19688@debbugs.gnu.org > > > > Any chance to check out the patches yet? > > It's on my todo. Sorry for the long delay (life intervened). After reading the last messages, I must ask that we back up a notch and discuss something I'm not sure I understand correctly. Specifically, this issue: > >> >> +#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. Maybe I'm missing something, but I don't see a pipe being used on Unix for synchronization between emacsclient and the daemon started by emacsclient. Rather, on Unix we do this: dpid = fork (); if (dpid > 0) { pid_t w; w = waitpid (dpid, &status, WUNTRACED | WCONTINUED); if ((w == -1) || !WIFEXITED (status) || WEXITSTATUS (status)) { message (true, "Error: Could not start the Emacs daemon\n"); exit (EXIT_FAILURE); } /* Try connecting, the daemon should have started by now. */ message (true, "Emacs daemon should have started, trying to connect again\n"); if ((emacs_socket = set_socket (1)) == INVALID_SOCKET) My reading of this is that we use 'waitpid' to tell us when the daemon has started and is ready to receive our connection. There's no pipe involved here, AFAICT. Am I missing something? My understanding is that your Windows variant of the above is to wait on an event that is signaled by Emacs when it starts in daemon mode. My question is: can we use something similar to Unix here, like 'WaitForInputIdle'? After all, the above call to 'waitpid' just tells us the daemon process is past its initialization stage, as far as the OS is concerned, which isn't too fine-grained. Perhaps even repeatedly calling 'GetExitCodeProcess' until it returns STILL_ACTIVE for the first time would be a faithful enough emulation of what 'waitpid' does here? Could you please try these techniques and see if they do the job? If they do, we can get rid of the event stuff, I think. Thanks. P.S. What's up with your copyright assignment? I still don't see it on file.