http://bugs.winehq.org/show_bug.cgi?id=9787
--- Comment #220 from Andrey Turkin andrey.turkin@gmail.com 2008-07-15 13:25:30 --- (In reply to comment #219)
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
You are mixing up accept_socket function and accept_socket handler. accept_socket return either NULL in case of error, or object in case of success. accept_socket handler, though, returns NTSTATUS just like all other handlers, so !status is true when and only when status is STATUS_SUCCESSFUL (which is equal to 0). AcceptEx_recv gets called only after successful accept.
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).
and the socket gets queued (at this point it should not have been in queue already, so not re-queued but queued) if accept_socket fails with EWOULDBLOCK. Worry no about mutexes and synchronization etc - wineserver _is not_ multithreaded, there can be no two simultaneous requests. wineserver essentially runs in big loop, reading and executing one request at the time.
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.
Totally agree, it should be! Unfortunately, currently async code in wineserver does not allow restarting request after server->client call, or attaching same request to another fd, which is necessary to correctly implement AcceptEx (and also do the same for TransmitFile/TransmitPackets and maybe some other advanced i/o functions)