bug#17510: 24.3.91; Problem with `emacs --daemon' in cygw32 build

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 18 May 2014 10:30:28 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: 17510@debbugs.gnu.org, dmantipov@yandex.ru
> 
> On 5/18/2014 12:32 AM, Eli Zaretskii wrote:
> > Thanks, but you need to be more selective: which one of these changes
> > is the root cause, and why?
> 
> It's not easy to be selective; these aren't independent changes.  There 
> used to be a `w32_display_name_list', which Dmitry removed.  Along with 
> this change, he removed the code that used to be in x_delete_display (to 
> delete a display from the list) and replaced it by a FIXME.

Perhaps that FIXME is not relevant to Cygwin, and the removed code
should be retained in the Cygwin build.

> > In general, everything that is related to one_w32_display_info is
> > specific to the WINDOWSNT port, so perhaps the problem is that the
> > Cygwin-w32 build is incorrectly treated the same.  But where exactly?
> 
> Looking at the code, I don't see why this problem is specific to the 
> Cygwin-w32 build.

If the Cygwin-w32 build wants more (or less) than one display_info
object, then that part _is_ specific to Cygwin, because the native
Windows build has only one such object that is never deleted.

> Can you reproduce it in the Windows build?

The native Windows build doesn't support --daemon, so no, I can't.

> I *think* what must be happening in the recipe that I gave for this bug 
> is that every time a client frame is closed, x_delete_display is called. 
>   Before Dmitry's change, this would actually delete something from a 
> list.  Now it doesn't, and the server gets messed up and ultimately dies 
> on the third attempt to create a client frame.

See above: try restoring that code for Cygwin only.

> Unless there's an obvious fix for this, it seems to me that we're far 
> enough into the pretest that we should just revert to the old code, at 
> least for emacs-24.

That would revert a useful cleanup, which I'm not sure is a good idea
at this point.