[PATCH v2 2/2] ntdll: sock_recv keeps message ordered

[Dongwan Kim]

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.