Berend Ozceri wrote:
> I am a bit unfamiliar with the way the socket connect operation is split
> between the wine program and the wineserver - could someone tell me exactly
> what the expected sequence of events for a connect operation is? What is
> expected to trigger the calling of sock_poll_event() which seems to be the
> only place that sock->errors[FD_CONNECT_BIT] is set to a known value.
OK. The following short patch seems to do the right thing:
Index: wine/dlls/winsock/socket.c
===================================================================
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.17
diff -u -r1.17 socket.c
--- wine/dlls/winsock/socket.c 2000/06/18 17:23:17 1.17
+++ wine/dlls/winsock/socket.c 2000/06/21 09:11:41
@@ -256,7 +256,7 @@
{
/* do a dummy wineserver request in order to let
the wineserver run through its select loop once */
- (void)_is_blocking(s);
+ _enable_event(s, 0, 0, 0);
}
static int _get_sock_error(SOCKET s, unsigned int bit)
Does this look reasonable to everyone? Replacing _is_blocking() with a no-op
_enable_event() seems to guarantee that sock_reselect() will get called on the
wineserver side, causing sock_poll_event() to update the connection status and
result of the socket.
Unless somebody thinks this is horribly broken, I'll submit it to wine-patches
tomorrow.
Berend
