Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller <eller.helmut@gmail.com>]

* Eli Zaretskii [2010-03-27 12:11+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> 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.

But the code in wait_reading_process_output does use getsockopt inside
#ifdef GNU_LINUX and a very odd way to extract some error code in the
#else branch.  Despite that it's also inside an #ifdef
NON_BLOCKING_CONNECT.  Note that src/s/ms-w32.h defines
BROKEN_NON_BLOCKING_CONNECT.  In summary that code path is hardly ever
executed.

> 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?  

a) Trust the Windows API documentation for getsockopt.  Judging from the
documentation alone there's little reason to assume that it wouldn't
work in a similar way as on Unix.

or b) reproduce the scenario described in bug 5173 on Windows to see if
connect returns EINTR and getsockopt works.

> 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.

Writing code as described in the API documentation seems reasonable to
me.

I also had asked some questions regarding this code in
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00337.html but
nobody answered.  Then I filed bug 5173 that was ignored too.  When bug
5723 popped up I asked the same question again, bug again the
maintainers didn't know the answer but they decided to put some code
into trunk for testing.  I don't see what's wrong with this approach.

Helmut