Ho Bozo,
Thank you for comments and the suggested patch. I would prefer a
solution that did not have a special Windows-only-sometimes call
"pn_io_no_iocp()". It seems to me anyway that there is another class
of sockets that are pulled into an IOCP context too early, so that a
separate solution is required that should fix your problem too.
Basically, a more lazy enlistment strategy should leave you outside
IOCP and fix the other issue too.
Based on your problem and how Dispatch strives for multithreaded
performance, I think I have a better handle on what Proton should be
providing for small to medium-large scalability.
I am going to try to define what is a sensible intersection of Windows
and Posix capabilities to be supported by the proton
io/selector/selectable classes in a separate documentation JIRA and
try to get a fix for you ASAP, probably in yet another JIRA.
Cliff
On Fri, Sep 5, 2014 at 3:18 AM, Bozo Dragojevic <bo...@digiverse.si> wrote:
> On 5. 09. 14 11:53, Bozo Dragojevic wrote:
>>
>>
>> The patch is a bit rough
>> - not sure I really like the name pn_io_no_iocp()
>> - missing non-windows stub for pn_io_no_iocp()
>> - it most likely handles the selector access wrong (see XXX comment)
>
> I missed this bit (blush)
>
> diff --git a/proton-c/src/windows/io.c b/proton-c/src/windows/io.c
> index f9c85b4..b5fc7b2 100644
> --- a/proton-c/src/windows/io.c
> +++ b/proton-c/src/windows/io.c
> @@ -263,6 +263,14 @@ pn_socket_t pn_connect(pn_io_t *io, const char
> *hostarg, const char *port)
> if (io->iocp != NULL) {
> sock = pni_iocp_begin_connect(io->iocp, sock, addr, io->error);
> } else {
> + if (connect(sock, addr->ai_addr, addr->ai_addrlen) != 0) {
> + if (WSAGetLastError() != WSAEWOULDBLOCK) {
> + pni_win32_error(io->error, "connect", WSAGetLastError());
> + freeaddrinfo(addr);
> + closesocket(sock);
> + return INVALID_SOCKET;
> + }
> + }
> freeaddrinfo(addr);
> }
> return sock;
>
> Bozzo
