bug#19688: [patch] add support for emacs daemon on Windows

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On 01/25/2015 11:40 PM, Mark Laws wrote:
> On Mon, Jan 26, 2015 at 3:00 PM, Eli Zaretskii <eliz@gnu.org> 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 <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?
> 
> 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.

Inheriting an anonymous event feels a bit cleaner to me; you can provide
the HANDLE value in an environment variable or a command line parameter.
Failing that, the event name should at least contain "emacs" somewhere
so as to not confuse people browsing named object directories.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]