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?