[PATCH v4 4/8] server: Defer postprocessing until after setting initial status in send_socket handler.

[Jinoh Kang]

On 3/5/22 02:51, Zebediah Figura wrote:
> On 3/3/22 07:30, Jinoh Kang wrote:
>> This allows the client to postpone the initial I/O until the server has
>> queued the I/O request.  The server should perform the postprocessing
>> only after the initial I/O has been done.
>>
>> In the case of send_socket, the manipulation of event flags shall
>> ideally be done *after* (not *before*) the client has attempted the
>> initial I/O, since the outbound queue status of the socket may change in
>> the meanwhile.  Also, the implicitly bound address is available only
>> after the send* system call has been performed.
>>
>> Signed-off-by: Jinoh Kang <jinoh.kang.kr at gmail.com>
>> ---
>>
>> Notes:
>>      v1 -> v2:
>>      - pass around total size of data to be transmitted
>>      - detect short write in send_socket_initial_callback
>>      v2 -> v3: no changes
>>      v3 -> v4: no changes
>>
>>   dlls/ntdll/unix/socket.c | 15 ++++++++++++++
>>   server/protocol.def      |  1 +
>>   server/sock.c            | 42 +++++++++++++++++++++++++++-------------
>>   3 files changed, 45 insertions(+), 13 deletions(-)
>>
> 
> I still am failing to see the need to do this, especially by adding a new callback. What's preventing send_socket from working the same way as recv_socket?

As stated in the commit message, none of the actions in send_socket_initial_callback can be performed *before* the initial I/O.

In send_socket, "send() calls only clear and reselect events if unsuccessful."
We can tell if the I/O has succeeded only after set_async_direct_result.
Therefore, we can only clear and reselect events after the client tells us the initial I/O has been unsuccessful.

> Also, the implicitly bound address is available only
> after the send* system call has been performed.

-- 
Sincerely,
Jinoh Kang