Re: Escaping from blocked send() reprised.

On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
>    To make the code mentioned above (Patch 0002) tidy, rewrite the
>    socket emulation code for win32 backends so that each socket
>    can have its own non-blocking state. (patch 0001)

The first patch that makes non-blocking sockets behave more sanely on 
Windows seems like a good idea, independently of the second patch. I'm 
looking at the first patch now, I'll make a separate post about the 
second patch.

> Some concern about this patch,
>
> - This patch allows the number of non-blocking socket to be below
>    64 (FD_SETSIZE) on win32 backend but it seems to be sufficient.

Yeah, that's plenty.

> - This patch introduced redundant socket emulation for win32
>    backend but win32 bare socket for Port is already nonblocking
>    as described so it donsn't seem to be a serious problem on
>    performance. Addition to it, since I don't know the reason why
>    win32/socket.c provides the blocking-mode socket emulation, I
>    decided to preserve win32/socket.c to have blocking socket
>    emulation. Possibly it can be removed.

On Windows, the backend has an emulation layer for POSIX signals, which 
uses threads and Windows events. The reason win32/socket.c always uses 
non-blocking mode internally is that it needs to wait for the socket to 
become readable/writeable, and for the signal-emulation event, at the 
same time. So no, we can't remove it.

The approach taken in the first patch seems sensible. I changed it to 
not use FD_SET, though. A custom array seems better, that way we don't 
need the pgwin32_nonblockset_init() call, we can just use initialize the 
variable. It's a little bit more code, but it's well-contained in 
win32/socket.c. Please take a look, to double-check that I didn't screw up.

- Heikki