Re: Streaming Replication on win32

2010/2/8 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
> On Mon, Jan 18, 2010 at 11:46 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> From what I can tell, this indicates that pq_getbyte_if_available() is
>>>> not working - because it's supposed to never block, right?
>>>
>>> Right, it's not supposed to block.
>>>
>>>> This could be because the win32 socket emulation layer simply wasn't
>>>> designed to deal with non-blocking sockets. Specifically, it actually
>>>> *always* sets the socket to non-blocking mode, and then uses that to
>>>> properly emulate how sockets work under unix.
>>>
>>> I presume the win32 emulation layer can be taught about non-blocking
>>> sockets? Or maybe pq_getbyte_if_available() can be implemented using
>>> some other simpler method on Windows.
>>
>> It could be taught that, but it would probably be a lot easier to put
>> platform specific code in pq_getbyte_if_available().
>
> Umm.. in this case, for SSL on win32 case, we also need to create
> new function like my_sock_read_if_available() that receives data
> from non-blocking socket, and reassign it to the SSL BIO function.
> Right? If so, it seems easier for me to tell the win32 layer about
> non-blocking.

Sorry about the delay in responding to this.

Remember that the win32 code *always* puts the socket in non-blocking
mode. So we can't just "teach the layer about it". We need some way to
pass the information down that this is actually something we want to
be non-blocking, and it can't be the normal flag on the socket. I
don't really have an idea of where else we'd put it though :( It's in
the port structure, but not beyond it.

What we could do, is have an ugly global flag specifically for the
use-case we have here. Assuming we do create a plataform specific
pq_getbyte_if_available(), the code-path that would have trouble now
would be when we call pq_getbyte_if_available(), and it in turns asks
the socket if there is data, there is, but we end up calling back into
the SSL code to fetch the data, and it gets an incomplete packet.
Correct? So the path is basically:

pq_getbyte_if_available() -> secure_read() -> SSL_read() ->
my_sock_read() -> pgwin32_recv()

Given that we know we are working on a single socket here, we could
use a global flag to tell pgwin32_recv() to become nonblocking. We
could set this flag directly in the win32-specific version of
pq_getbyte_if_available(), and make sure it's cleared as soon as we
exit.

It will obviously fail if we do anything on a *different* socket
during this time, so it has to be set for a very short time. But that
seems doable. And we don't call any socket stuff from signal handlers
so that shouldn't cause issues.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/