Re: g_io_add_watch and non-blocking io on windows

[Tor Lillqvist <tml iki fi>]

Alexander Semyonov writes:
> My problem is that condition parameter in callback is always G_IO_OUT even
> if target host:port is unreachable. How can I discover that connect was
> unsuccessfull? Thanx.

The root cause for this apparently is that the giowin32.c code doesn't
check whether the connection actually succeeded or not when
WSAEnumNetworkEvents() returns with the FD_CONNECT bit set in the
WSANETWORKEVENTS.

Reading the fine documentation for connect() on MSDN, it clearly says
that when using the WSAEventSelect() mechanism (which giowin32.c
does), the event will fire and WSAEnumNetworkEvents() will return with
the FD_CONNECT bit set in WSANETWORKEVENTS.lNetworkEvents when the
connection attempt has finished, successfuly or not.

Whether it succeeded or not should be checked from the error code
corresponding to FD_CONNECT in the WSANETWORKEVENTS.iErrorCode. This
is what giowin32.c should do, if it needs to differentiate. (Which is
not 100% clear, read on...)

What do you expect to happen if the connection fails? Presumably that
your callback function is called with G_IO_ERR? Is that what happens
on Unix? (Your test program only contains Win32 code to set up the
socket.) Or is that G_IO_ERR just your guess?

Could it be G_IO_HUP that one should look for instead? (That wouldn't
be entirely logical, if there hasn't been any connection in the first
place, how can it be hung up...?)

Or could it really be that G_IO_OUT is actually the right event to get
even when the connection didn't succeed, and it's then up to notice
that the socket is not connected only when actually attempting to send
that? That would be rather silly, I think.

--tml