[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MS-Windows build broken in Fmake_network_process
From: |
Helmut Eller |
Subject: |
Re: MS-Windows build broken in Fmake_network_process |
Date: |
Sat, 27 Mar 2010 14:56:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
* Eli Zaretskii [2010-03-27 12:11+0100] writes:
>> 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.
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
- Re: Serious performance problem with process output on Mac OSX, (continued)
- Re: MS-Windows build broken in Fmake_network_process, Davis Herring, 2010/03/29
- Re: MS-Windows build broken in Fmake_network_process, Jason Rumney, 2010/03/30
- Re: MS-Windows build broken in Fmake_network_process, Helmut Eller, 2010/03/27
- Re: MS-Windows build broken in Fmake_network_process, Eli Zaretskii, 2010/03/27
- Re: MS-Windows build broken in Fmake_network_process, Helmut Eller, 2010/03/27
- Re: MS-Windows build broken in Fmake_network_process, Eli Zaretskii, 2010/03/27
- Re: MS-Windows build broken in Fmake_network_process,
Helmut Eller <=
- Re: MS-Windows build broken in Fmake_network_process, Juanma Barranquero, 2010/03/26
Re: MS-Windows build broken in Fmake_network_process, YAMAMOTO Mitsuharu, 2010/03/26