|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>|
|Cc:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Escaping from blocked send() reprised.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2014-09-02 21:22:29 +0300, Heikki Linnakangas wrote:
> 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
> 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, what's your plan about this patch? Do you plan to commit it?
|Next Message||Manuel Kniep||2015-01-16 12:21:28||Re: segmentation fault in execTuples.c#ExecStoreVirtualTuple|
|Previous Message||Heikki Linnakangas||2015-01-16 11:31:10||Re: More Norwegian trouble|