On 6/11/2013 2:50 PM, Paul Eggert wrote:
> On 06/11/13 09:58, Eli Zaretskii wrote:
>> Can you find out (by looking at the glib sources) when and why would
>> g_spawn_close_pid call 'abort'?  It might give us some clues.
>
> On POSIX platforms, g_spawn_close_pid does nothing.
> So apparently glib is compiled for Windows (i.e.,
> glib/gspawn.c is not being compiled, but glib/gspawn-win32.c
> is being compiled instead.

No, this is not the case.  I just replicated the glib build to make 
sure.  Cygwin is a POSIX platform, to the extent possible.

> The Emacs code that tickles gnulib is written this way:
>
> #if defined HAVE_GLIB && !defined WINDOWSNT
>        /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
> 	 this should always fail, but is enough to initialize glib's
> 	 private SIGCHLD handler.  */
>        g_source_unref (g_child_watch_source_new (getpid ()));
> #endif
>
> I did notice one problem: the code previously invoked
> g_child_watch_source_new (0), which is not safe if Emacs
> has already forked -- perhaps Cygwin was doing that?
> So I changed it to g_child_watch_source_new (getpid ())
> in trunk bzr 112929.
>
> Another thought is that there may be a mismatch between
> glib builds.  Since WINDOWSNT is not defined for Cygwin builds,
> a Cygwin Emacs will call g_child_watch_source_new.  My reading of
> the bleeding-edge glib source code is that a Cygwin glib should call
> waitpid and mess with the SIGCHLD handler, just as a
> POSIX glib would, so the above Emacs code is correct.
> But if you're building under Cygwin and linking with
> a mingw glib, the above code may well run into problems.
> Is this a possibility that we should worry about?

No.  This does not happen.  The Cygwin glib maintainer takes pains to 
patch the source if necessary to make sure that Cygwin is not treated 
like Windows.  See, for instance, the attached patch that is used in the 
Cygwin build.

Ken