[PATCH v2 2/2] ntdll: sock_recv keeps message ordered
Dongwan Kim
kdw6485 at gmail.com
Thu Dec 9 21:01:15 CST 2021
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.
More information about the wine-devel
mailing list