Hello,
> > - 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.
I see, thank you.
> 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.
Thank you. I felt a bit qualm to abusing fd_set. A bit more code
is not a problem.
I had close look on your patch.
Both 'nonblocking' and 'noblock' are appears in function names,
pgwin32_set_socket_block/noblock/is_nonblocking(). I prefer
nonblocking/blocking pair but I'm satisfied they are in uniform
style anyway. (Though I also didn't so ;p)
pgwin32_set_socket_block() leaves garbage in
nonblocking_sockets[] but it's no problem practically. You also
removed blocking'ize(?) code but I agree that it is correct
because fds of nonclosed socket won't be reused anyway.
pg_set_block/noblock() made me laugh. Yes you're correct. Sorry
for the bronken (but workable) code.
After all, the patch looks pretty good.
I'll continue to fit the another patch onto this.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center