Skip to content

gh-109532: fix socket HOWTO inaccuracy about send() on broken connection #144747

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Gh-Novel wants to merge 2 commits into
base: main
Choose a base branch
from
Open

gh-109532: fix socket HOWTO inaccuracy about send() on broken connection #144747

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
18fa493
gh-109532: fix socket HOWTO inaccuracy about send() on broken connection
Gh-Novel Feb 12, 2026
0cf09b4
Address review: better emphasize send() vs recv() behavior
Gh-Novel Feb 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions Doc/howto/sockets.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -167,9 +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 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.* 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
Expand Down Expand Up @@ -201,6 +203,8 @@ length message::
sent = self.sock.send(msg[totalsent:])
if sent == 0:
Copy link
Contributor

@bkap123 bkap123 Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think that we can get rid of this if clause and the RuntimeError exception since send will already raise an error on a broken connection. That would also make more sense because your comment below is basically saying that send raises an error automatically so there is no reason to check its return value.

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):
Expand Down
Loading