From: "Zebediah Figura (she/her)" <zfigura@codeweavers.com>
Subject: Re: [RFC PATCH v2 04/11] server: Attempt to complete I/O request immediately in recv_socket.
Message-Id: <8aff03eb-cba6-0b32-5ba5-c133d5063abf@codeweavers.com>
Date: Wed, 26 Jan 2022 17:35:37 -0600
In-Reply-To: <0698de20-4414-7eed-1a38-eb739cf4d7d1@gmail.com>
References: <1e0d520b-0f60-1323-3305-4f884fb121a1@gmail.com> <d137b943-0f6a-06a8-4348-f7975d70f120@gmail.com> <eb786278-98c2-490d-deb5-3ac57b21a16e@codeweavers.com> <0698de20-4414-7eed-1a38-eb739cf4d7d1@gmail.com>

On 1/25/22 20:29, Jinoh Kang wrote:
> On 1/26/22 03:23, Zebediah Figura (she/her) wrote:
>> On 1/22/22 08:36, Jinoh Kang wrote:
>>> diff --git a/include/wine/afd.h b/include/wine/afd.h
>>> index efd5787e90a..1e26739229d 100644
>>> --- a/include/wine/afd.h
>>> +++ b/include/wine/afd.h
>>> @@ -37,6 +37,23 @@ struct afd_wsabuf_32
>>>    # define WS(x)    x
>>>    #endif
>>>    +
>>> +/* Used in the iosb.result field to indicate that the current socket I/O
>>> + * operation is in synchronous non-blocking mode.  This value is normally
>>> + * transmitted via the APC_ASYNC_IO system APC call (with status STATUS_ALERTED)
>>> + * when the server gives the client a chance to complete the I/O synchronously
>>> + * before resuming the request as fully asynchronous I/O or failing it.
>>> + * If the I/O fails with EWOULDBLOCK and the iosb.result field is set to any
>>> + * other value, the client shall request the server to resume the asynchronous
>>> + * operation.
>>> + *
>>> + * The value (ULONG_PTR)-1 (the maximum value of ULONG_PTR) is chosen so that
>>> + * it will be least likely to be confused with "the number of bytes transferred
>>> + * so far."  Any I/O operation that has made it to the maximum number of bytes
>>> + * shall complete immediately anyway.
>>> + */
>>> +#define AFD_WINE_IN_NONBLOCKING_MODE ((ULONG_PTR)-1)
>>> +
>>
>> Why add this instead of returning a separate field from the recv_socket request?
> 
> It's not intended to be returned from recv_socket request.
> 
>> This value is normally transmitted via the APC_ASYNC_IO system APC call (with status STATUS_ALERTED)
>> transmitted via the APC_ASYNC_IO system APC call (with status STATUS_ALERTED)
>> when the server gives the client a chance to complete the I/O synchronously
> 
> Do you have any suggestion as to how to better pass the blocking/nonblocking flag to async_recv_proc()?
> 

Okay, I see the problem. I guess the approach of reusing APC 
infrastructure may not be as palatable after all.

I'll take a look at the series beginning with 224085; it looks 
potentially better...