I finished embedding the test into ws2_32/tests.
Can I submit this patch with the patch for ws2_32/test? Without it, I cannot pass the Marvin(test bot).
So, with my fears about the necessity of this feature confirmed, I think the right way to implement it is actually to unconditionally get rid of the initial try_recv call. Trying to do it conditionally is pretty much impossible without races.
You mean the case that two processes share a socket? I agree. For instnace, process A makes pending asyncs and process B calls WSARecv for the first time in its lifetime. At that time, the message comes and wine server is busy. Then, process B might intercept the message because it has not received aysnc APC ever. I did not tested this case in Windows. This situation might be really rare in that other applications work well in current wine.
This will, however, introduce an extra server call in some cases. Specifically, if there is already data available (and we are the first in line) we currently make two server calls (one to report STATUS_SUCCESS to the server, and one to select on the async handle). With this change we'll make three. (Note that it looks like two, because we're still doing a call to NtWaitForSingleObject, but being interrupted by a kernel APC means we restart the select call.)
Actually, I can't understand why an extra server call occurs. It might be there's something I don't know. In this patch, I just added extra data about pending asyncs to existing apc_call data(apc_call_t). At your example, there are no pending asyncs because we are the first in line. ( Do I understand correctly?) queue->read_q ( it is the structure created in this patch) was cleared to 0 when the last APC_ASYNC_IO came. So It would behave exactly the same with current wine in this situation. Please let me know what I missed.
Thanks.