Performance: investigate whether repetetive recv/recvfrom until EAGAIN is a good idea.

[tarasko]

Current implementation in data_received and datagram_received path is reading only once and then rely on the loop to call it again, which basically mean there will be epoll_wait or similar before we read again.

AI did research on other libraries:

Short version: there is no single universal strategy. The high-performance libraries split into two styles.

Operation-Based
Boost.Asio and Tokio mostly expose one receive operation as one completion.

For UDP:

• Boost.Asio async_receive_from() starts one async datagram receive. The user provides the buffers and endpoint storage, and the handler gets one completion with bytes_transferred. It does not expose “drain until EAGAIN” as
  the semantic of one async receive. Source: Boost.Asio async_receive_from docs: https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/basic_datagram_socket/async_receive_from/overload1.html

• Tokio UdpSocket::poll_recv_from() explicitly “attempts to receive a single datagram”. recv_from().await is one datagram. Users who want batching usually loop themselves around readiness/try_recv_from. Source: Tokio UDP
  docs: https://docs.rs/tokio/latest/tokio/net/struct.UdpSocket.html

For streams:

• Boost.Asio async_read_some() may read less than the supplied buffer and completes one operation. Higher-level async_read() is the looped “read until condition” helper. Source:
  https://live.boost.org/doc/libs/1_85_0/doc/html/boost_asio/reference/basic_stream_socket/async_read_some.html

• Tokio has readiness plus try_read(): wait for readable, try one read, and if it hits WouldBlock, readiness is cleared. Users can loop if they want to drain. Source: Tokio TCP docs:
  https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html

This style favors predictable latency/fairness and lets application code decide batching.

Callback/Handle-Based
libuv is more aggressive internally.

For streams:

• uv_read_start() says the read callback is made “several times until there is no more data to read or uv_read_stop() is called.” It also documents nread == 0 as equivalent to EAGAIN / EWOULDBLOCK. Source: libuv stream docs:
  https://docs.libuv.org/en/latest/stream.html

For UDP:

• libuv’s UDP docs say the receive callback can be called with nread == 0 and addr == NULL when there is nothing to read.
• It has optional UV_UDP_RECVMMSG; when enabled and supported, it uses recvmmsg(2), and docs recommend buffers that are multiples of 64 KiB. Source: libuv UDP docs: https://docs.libuv.org/en/v1.x/udp.html
• The Unix source uses a bounded loop for UDP receive, with a starvation guard (count = 32), not an unlimited drain. It also supports recvmmsg batching. Source example:
  https://fuchsia.googlesource.com/third_party/cmake/+/3e84a06b3aa2715dd61537db624d6371813c0a1b/Utilities/cmlibuv/src/unix/udp.c

What This Means For aiofastnet
For asyncio-compatible Python transports, the Boost/Tokio style is closer semantically: one readiness callback, one datagram_received for UDP. That matches what just fixed your regression.

For stream data_received, libuv’s strategy supports looping, but with a cap/fairness guard. I would not do unconditional drain-until-EAGAIN in Python/Cython if it allocates before the failing syscall. A better experiment is:

• UDP: one recv per readiness callback.
• Stream: maybe retry only if the previous read filled the whole buffer.
• Optional later: bounded read_batch_limit, e.g. 1, 4, 16, 32.
• Avoid allocating the Python bytes object before a speculative read that may return EAGAIN, if we ever reintroduce draining.

[tarasko]

Closed by #61