all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Mark Laws <mdl@60hz.org>
Cc: 19688@debbugs.gnu.org
Subject: bug#19688: [patch] add support for emacs daemon on Windows
Date: Mon, 26 Jan 2015 08:00:37 +0200	[thread overview]
Message-ID: <83d262qdx6.fsf@gnu.org> (raw)
In-Reply-To: <CADemMPM+Tix-6FJ+CO3HA8y7Cq6AV0kv_e6_qn7BaSw1QMOwTQ@mail.gmail.com>

[Please keep the bug address on the CC list, so that this whole
discussion gets archived.]

> Date: Mon, 26 Jan 2015 08:16:38 +0900
> From: Mark Laws <mdl@60hz.org>
> 
> >> +#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?

> Moved to ms-w32.h and removed changes relating to the header.

Thanks.

> >> +#else
> >> +bool w32_is_daemon;
> >> +bool w32_daemon_is_initialized;
> >> +static HANDLE w32_daemon_event;
> >> +#endif
> >
> > 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.

> >> +#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].

> > 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.

Thanks.





  parent reply	other threads:[~2015-01-26  6:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-25 19:18 bug#19688: [patch] add support for emacs daemon on Windows Mark Laws
2015-01-25 20:34 ` Eli Zaretskii
     [not found]   ` <CADemMPM+Tix-6FJ+CO3HA8y7Cq6AV0kv_e6_qn7BaSw1QMOwTQ@mail.gmail.com>
2015-01-26  6:00     ` Eli Zaretskii [this message]
2015-01-26  7:40       ` Mark Laws
2015-01-26 11:56         ` Daniel Colascione
2015-01-27  8:40           ` Mark Laws
2015-01-30  0:36             ` Mark Laws
2015-01-30  6:28               ` Eli Zaretskii
2015-02-13  0:07                 ` Mark Laws
2015-02-13  8:49                   ` Eli Zaretskii
2015-02-14 12:10                     ` Eli Zaretskii
2015-02-14 13:16                       ` Mark Laws
2015-02-14 13:28                         ` Eli Zaretskii
2015-02-14 13:37                           ` Mark Laws
2015-02-14 15:24                             ` Eli Zaretskii
2015-02-14 16:34                               ` Mark Laws
2015-02-14 16:53                                 ` Eli Zaretskii
2015-02-14 16:57                                   ` Mark Laws
2015-02-14 17:23                                     ` Eli Zaretskii
2015-02-14 17:30                                       ` Mark Laws
2015-02-14 17:42                                         ` Eli Zaretskii
2015-02-14 17:57                                           ` Mark Laws
2015-02-14 18:26                                             ` Eli Zaretskii
2015-02-14 19:21                                               ` Mark Laws
2015-02-14 19:29                                                 ` Eli Zaretskii
2015-02-14 21:15                                                   ` Mark Laws
2015-02-19 16:31                                                     ` Mark Laws
2015-02-19 16:56                                                       ` Eli Zaretskii
2015-02-21 13:03                                                         ` Eli Zaretskii
2015-02-21 19:30                                                           ` Mark Laws
2015-02-27 14:26                                                             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83d262qdx6.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=19688@debbugs.gnu.org \
    --cc=mdl@60hz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.