GNU bug report logs - #19688
[patch] add support for emacs daemon on Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Laws <mdl <at> 60hz.org>
Cc: 19688 <at> debbugs.gnu.org
Subject: bug#19688: [patch] add support for emacs daemon on Windows
Date: Sat, 14 Feb 2015 17:24:42 +0200

> Date: Sat, 14 Feb 2015 22:37:55 +0900
> From: Mark Laws <mdl <at> 60hz.org>
> Cc: 19688 <at> debbugs.gnu.org
> 
> On Sat, Feb 14, 2015 at 10:28 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > I don't see why 'WaitForInputIdle' wouldn't work.  Can you explain?
> > AFAIU, it waits until the process is idle, which means it did all the
> > initialization and is ready for accepting connections.  Am I missing
> > something?
> 
> http://blogs.msdn.com/b/oldnewthing/archive/2010/03/26/9985422.aspx

Thanks, it's good to know about those subtleties.

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.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.