[patch] Winsock fixes
ovehk at ping.uio.no
Thu Nov 29 06:24:18 CST 2001
On Wed, 28 Nov 2001, Paul Rupe wrote:
> I have found two bugs in dlls/winsock/socket.c. One I posted about a
> few days ago in wine.devel. WS_accept calls WS_getpeername but passes
> it the Unix file descriptor rather than the Windows socket handle. A
> simple one-line change takes care of that.
That's Francois's fault, when he split out the sockaddr_xxx conversions.
> The second problem is more subtle, and I'm not sure if my solution is
> enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all
> events currently available on the socket. The problem is the order, it
> simply calls them in increasing order by FD_xxx values. Since FD_READ
> is numerically smaller than FD_CONNECT, a socket that has both events
> will fire the read event before the connect. When that happens, the app
> gets a read event before it thinks it's connected and ignores it.
> Ideally, the loop should post them in the order in which they occurred,
> but does wine keep track of that? Instead, I changed the loop so that
> it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not
> sure if the order I chose is the optimal one, but the app I was testing
> (Xnews) works every time now.
It'd seem to me that FD_CLOSE should be dispatched last, not first...
Anyway, now that Alexandre moved the window message queues away from the
wine clients and into the wineserver, these event message dispatches could
also be done in the wineserver (where the winsock events are generated),
instead of using the service thread callback WINSOCK_DoAsyncEvent.
Alexandre wants to phase out the service thread anyway, so he probably
won't oppose this. Any volunteers for that?
More information about the wine-devel