Re: Escaping from blocked send() reprised.
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Escaping from blocked send() reprised. |
Дата | |
Msg-id | 20140905.154205.167219106.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Escaping from blocked send() reprised. (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: