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

[Mark Laws]

On Sun, Feb 15, 2015 at 12:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> However, after looking at the Emacs initialization code, I think those
> problems will not affect Emacs, because we only start the thread that
> reads Windows messages inside the call to Frecursive_edit, and by that
> time the daemon initialization is already done.
>
> OTOH, there's one other caveat in the documentation of
> 'WaitForInputIdle': it returns immediately "if the process is a
> console application or does not have a message queue".  Emacs is built
> as a console application, and I'm not sure at which point it begins to
> "have a message queue", as far as this function is concerned.
>
>> I can try it if you want, but it seems fragile compared to the event thing.
>
> Please do try it, I think it will either work reliably or not at all.
>
> The reason I'd prefer to use it if it works is because doing so
> side-steps the entire issue of how to pass the event ID, which,
> together with the code which handles the event, adds non-trivial
> amount of code to your patch.  It would be nice to avoid that, if
> possible.

I gave it a try, but it doesn't work--most likely because, as you
said, Emacs is built as a console application, so WaitForInputIdle
simply returns immediately because of the race between emacsclient
attempting to wait on Emacs and Emacs establishing a Windows message
queue. So, the options are either using an event or modifying Emacs to
run under the Windows subsystem--I don't think I need to tell you
which one is the less invasive change. :)

-- 
|v\ /\ |\ |< |_ /\ \^| //