bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Colascione
Subject: bug#19688: [patch] add support for emacs daemon on Windows
Date: Mon, 26 Jan 2015 03:56:28 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]