[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: |
Eli Zaretskii |
Subject: |
Re: MS-Windows build broken in Fmake_network_process |
Date: |
Sat, 27 Mar 2010 11:44:30 +0300 |
> Date: Sat, 27 Mar 2010 09:51:56 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: Helmut Eller <address@hidden>,
> address@hidden
>
> Actually I was aware of the above part when I committed the change in
> question. But the code above was added in 2002, and I doubted whether
> it is still the case for the systems that are supported by Emacs
> 24.0.50. So I didn't copy the above code for Fmake_network_process.
I don't know which systems Kim Storm (who wrote that code; CC'ed) had
in mind when he made it conditional on GNU/Linux. The related
discussion on emacs-devel does not talk about this issue, and the
preliminary version of the patch Kim posted back then does not include
the conditional GNU/Linux code.
But let me remind you that Windows XP, the Windows version that is
still the most widely used one today, was released in 2002.
> Can normal (i.e., blocking) `connect' in Windows be interrupted by a
> POSIX signal counterpart? If not, then we can disable the whole added
> code for Windows in the first place.
As I said, I'm far from being an expert on the Windows socket library
and its operation. Here's what I know about the related issues:
. The Windows socket functions can only return EINTR (actually,
WSAEINTR, from which we produce EINTR in Emacs's Windows source)
only for the old Winsock 1.1 sockets, and only if some code calls
`WSACancelBlockingCall'. Emacs does not call that function
directly, and in fact it is deprecated and was removed from Winsock
2 library.
. C-g does not trigger an asynchronous SIGINT on Windows like it does
on Posix systems. Instead, the Emacs's Windows code has a separate
input thread; when that thread sees a C-g keystroke, it triggers a
special handle that is included in the set of handles on which
`select' waits. `select' then returns with -1 setting errno to
EINTR. This is how the Windows build interrupts prolonged ``system
calls''.
. Note that `select' itself is implemented (as `sys_select') in
Emacs's Windows code, i.e. we don't use the Windows-supplied
`select', which only works on network handles.
>From this I tend to conclude that `connect' on Windows cannot be
interrupted like on Posix systems, because when `connect' is called,
we are not waiting in `select'.
Perhaps Jason and Juanma can add their expertise to what I say above
and correct me where I'm wrong.
- Re: Serious performance problem with process output on Mac OSX, (continued)
- 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, 2010/03/27
- 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