On Wed, 21 Jun 2000, Berend Ozceri wrote:
> 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.
To answer your first question, sock_poll_event() is called from the
select_loop() at the bottom of server/select.c. The _is_blocking() was
supposed to make the wineserver run through that loop once, and then the
poll() in there would notice the connection and call the poll_event
function (which for sockets are sock_poll_event()). Do you know just
exactly what changed in Linux to make that poll loop not function like
it's supposed to?
I don't think the above patch should break anything, but if it actually
fixes something, then it's a sign that something else might be wrong.
