http://bugs.winehq.org/show_bug.cgi?id=9787
--- Comment #219 from Scott Lindeneau slindeneau@gmail.com 2008-07-15 12:21:50 --- (In reply to comment #216)
After working my way through more of the wineserver code I understand better that what you have implemented and what I have been thinking is similar. The threads I was thinking about are pre-built into the wineserver utilizing the async register and callbacks. Please forgive my ignorance regarding that. There is a lot of code here to sort through.
*Note: I am making these changes and testing as I am writing this, but it takes for ever to compile on my laptop and test. I will post results as I have them.
Regarding the missing connections (or the apparently missed connections), they could originate from the lack of implementing data_len correctly or status messages getting lost somewhere. For instance, as the patch is written:
+static NTSTATUS WS2_async_accept(void* user, IO_STATUS_BLOCK* iosb, NTSTATUS status) ... Edited for relevance + case STATUS_ALERTED: + SERVER_START_REQ( accept_socket ) + { ................ + status = wine_server_call( req ); + } + SERVER_END_REQ; + + if (!status) + { + status = AcceptEx_recv( ......); + }
The accept_socket function will only return NULL or 0 or FALSE when the accept_socket call fails, thus the AcceptEx_recv function is being called when there is accept function fails, which I believe is the incorrect behavior. I believe it should re-queue itself in the async queue due to the multi-threaded nature of the system. (I also believe the accept should be made atomic with mutex's but I don't know if thats implemented elsewhere or not in the async_queue functions or not).
The AcceptEx_recv call should happen inside of the else case of the if(!status), something like this:
if(!status) requeue else acceptex_recv
It is also possible that the acceptex_recv should be done asynchronously itself, and the windows error stack should not be updated until after the data is received.