From 18fa49322c3e5c909b84bca3a07b0985906e6a56 Mon Sep 17 00:00:00 2001 From: Firstminer Technology Date: Thu, 12 Feb 2026 18:26:18 +0530 Subject: [PATCH 1/2] gh-109532: fix socket HOWTO inaccuracy about send() on broken connection Correct the claim that send() returns 0 bytes on a broken connection. In practice, send() on a broken connection raises OSError (EPIPE) rather than returning 0. Only recv() returns 0 bytes to indicate disconnection. Add a clarifying comment to the mysend example noting this distinction. --- Doc/howto/sockets.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst index cbc49d15a0771b..593705c999dbbb 100644 --- a/Doc/howto/sockets.rst +++ b/Doc/howto/sockets.rst @@ -167,9 +167,10 @@ request, then reads a reply. That's it. The socket is discarded. This means tha a client can detect the end of the reply by receiving 0 bytes. But if you plan to reuse your socket for further transfers, you need to realize -that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a socket -``send`` or ``recv`` returns after handling 0 bytes, the connection has been -broken. If the connection has *not* been broken, you may wait on a ``recv`` +that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a +``recv`` returns 0 bytes, the connection has been broken. A ``send`` on a +broken connection will raise an :exc:`OSError` instead. If the connection has +*not* been broken, you may wait on a ``recv`` forever, because the socket will *not* tell you that there's nothing more to read (for now). Now if you think about that a bit, you'll come to realize a fundamental truth of sockets: *messages must either be fixed length* (yuck), *or @@ -201,6 +202,8 @@ length message:: sent = self.sock.send(msg[totalsent:]) if sent == 0: raise RuntimeError("socket connection broken") + # Note: in practice, send() on a broken connection + # raises OSError rather than returning 0. totalsent = totalsent + sent def myreceive(self): From 0cf09b41d05ba25bdcd95d450993c3eca179b37d Mon Sep 17 00:00:00 2001 From: Firstminer Technology Date: Thu, 19 Feb 2026 10:54:28 +0530 Subject: [PATCH 2/2] Address review: better emphasize send() vs recv() behavior MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Remove informal 'I repeat:' phrasing. Restructure paragraph to clearly contrast recv() returning 0 bytes (a deliberate signal of disconnection) with send() raising OSError (an error condition — should never be called on a broken socket). Co-authored-by: bkap123 --- Doc/howto/sockets.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst index 593705c999dbbb..eee375cf14534c 100644 --- a/Doc/howto/sockets.rst +++ b/Doc/howto/sockets.rst @@ -167,10 +167,11 @@ request, then reads a reply. That's it. The socket is discarded. This means tha a client can detect the end of the reply by receiving 0 bytes. But if you plan to reuse your socket for further transfers, you need to realize -that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a -``recv`` returns 0 bytes, the connection has been broken. A ``send`` on a -broken connection will raise an :exc:`OSError` instead. If the connection has -*not* been broken, you may wait on a ``recv`` +that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* If a ``recv`` +returns 0 bytes, the connection has been broken. In contrast, you should never +call ``send`` on a broken socket, as it will raise an :exc:`OSError` rather than +returning 0. If the connection has *not* been broken, you may wait on a +``recv`` forever, because the socket will *not* tell you that there's nothing more to read (for now). Now if you think about that a bit, you'll come to realize a fundamental truth of sockets: *messages must either be fixed length* (yuck), *or