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@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.