On Tue, 28 Jun 2022 at 14:08, <yla...@apache.org> wrote: > > Author: ylavic > Date: Tue Jun 28 11:08:32 2022 > New Revision: 1902312 > > URL: http://svn.apache.org/viewvc?rev=1902312&view=rev > Log: > apr_socket_sendv: WIN32: Limit the number of WSABUFs allocated for a single > call. > > * network_io/win32/sendrecv.c(): > Define WSABUF_ON_HEAP to 500. > > * network_io/win32/sendrecv.c(apr_socket_sendv): > Do not sendv more than WSABUF_ON_HEAP WSABUFs. > This commit changes the behavior for blocking sockets: now apr_socket_sendv() may result in a partial write.
As far I see apr_socket_sendv() does not explicitly document whether partial writes are allowed for *blocking* sockets. Posix send() seems to send all data [1]: [[ When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in nonblocking I/O mode. In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be used to determine when it is possible to send more data. ]] Also even APR code assumes that apr_socket_sendv() doesn't allow partial writes. See apr_memcache_delete() for example: https://demo-server.visualsvn.com/!/#asf/view/r1902313/apr/apr/trunk/memcache/apr_memcache.c?line=923 Not too sure that limiting the size of the malloc() is worth it in this case. What are the reasons to limit it? Another approach would be to split writes to multiple WSASend calls when iovec count is more than WSABUF_ON_STACK, but this would break implicit assumption that apr_socket_sendv() is atomic like writev [2]. PS: Do we have a test for such apr_socket_sendv() call? [1] https://linux.die.net/man/2/send [2] https://linux.die.net/man/2/writev -- Ivan Zhakov
