[PATCH 4/4] dlls/ntdll: Call try_recv inside sock_recv only if it is safe to do so.

[Jinoh Kang]

On 1/19/22 08:08, Zebediah Figura (she/her) wrote:

> 
> That aside, though, I'm not sure that adding a new select type is really the right way to go about this.

If we are not going with SIGNAL_WAIT_ASYNC, there's an alternate approach
(avoiding three server round trips):

1. Add a new wineserver request that calls async_set_result(), as in [1].
2. Re-implement async's add_queue to switch to pending mode before calling the
   original add_queue.

In this approach, Unix side will handle synchronous I/O operation as follows:

1. If the operation is completed, we request wineserver to call async_set_result() directly, and don't wait *at all*.
2. If the operation needs to be queued (STATUS_PENDING), we do async_wait() as before.
   This will "magically" switch the async to STATUS_PENDING and continue polling.

Note "magically" -- we're injecting impure semantics into async's pre-wait stage.
I don't think this would be a significant problem, since the "async" object type
is internal to Wine anyway.

> One approach that occurs to me, which might end up being simpler,

Reusing the APC machinery while keeping things simple turned out to be no easy task.
Perhaps I could just make the other [2] patch serie even simpler, but I'm stuck here...

> would be to return an apc_call_t, essentially as if the select request had been called immediately afterward. (In that case perhaps we should return STATUS_KERNEL_APC rather than STATUS_ALERTED).

[1] https://www.winehq.org/pipermail/wine-devel/2021-December/202825.html
[2] https://www.winehq.org/pipermail/wine-devel/2022-January/205168.html

-- 
Sincerely,
Jinoh Kang