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