Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <address@hidden>
> Date: Sat, 27 Mar 2010 11:09:17 +0100
> 
> > I don't argue about this code's correctness or necessity on Posix
> > systems.  I accept your and others' expert knowledge about that.  What
> > I'm saying is that this code is unneeded and possibly inappropriate on
> > Windows, where most of the system calls and mechanisms involved in
> > this issue work in an entirely different way under the hood.
> > Therefore, I submit that this code should have never been installed
> > unconditionally, at least not without discussing its applicability and
> > implications on Windows.
> 
> You seem to think that adding lots of #ifdefs is a good solution

No, I don't.  I think it's an ugly solution which should only be taken
as a last resort.  That is why I asked you to provide an alternative
solution that didn't use getsockopt, like the one we already have in
wait_reading_process_output.  I hoped that such an alternative
solution would avoid the #ifdef.

Failing that, unless we have on board an expert on Windows sockets, or
could find one, who could explain how this affects Windows, what else
can we do except #ifdef this code away?  I do think that it is a bad
idea to apply code that was written on very specific assumptions about
the underlying low-level system behavior, to platforms whose behavior
is fundamentally different.

> The code in question is not executed unconditionally.  It's inside an
> if(errno==EINTR).  If Windows' connect doesn't return EINTR the code is
> still correct and simpler than adding #ifdefs.

I didn't say Windows will never generate EINTR at that point.  I
simply don't know enough about the subject to analyze all the possible
flows which could lead to that point, and make sure none of them will
ever generate EINTR.  The original code did have this portion, which
was also run on Windows:

      if (xerrno == EINTR)
        goto retry_connect;