Re: [Python-Dev] [Python-checkins] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
Issue #7995: When calling accept() on a socket with a timeout, the returned socket is now always non-blocking, regardless of the operating system.
Seems clear enough
+ # Issue #7995: if no default timeout is set and the listening + # socket had a (non-zero) timeout, force the new socket in blocking + # mode to override platform-specific socket flags inheritance.
Slightly confusing
+ # Issue #7995: when calling accept() on a listening socket with a + # timeout, the resulting socket should not be non-blocking.
Seems to contradict the first. 'sould not be non-blocking' to me means 'should be blocking', as opposed to 'is now ... non-blocking'. Terry
On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
Issue #7995: When calling accept() on a socket with a timeout, the returned socket is now always non-blocking, regardless of the operating system.
Seems clear enough
+ # Issue #7995: if no default timeout is set and the listening + # socket had a (non-zero) timeout, force the new socket in blocking + # mode to override platform-specific socket flags inheritance.
Slightly confusing
+ # Issue #7995: when calling accept() on a listening socket with a + # timeout, the resulting socket should not be non-blocking.
Seems to contradict the first. 'sould not be non-blocking' to me means 'should be blocking', as opposed to 'is now ... non-blocking'.
Thank you for spotting the contradiction; this is now fixed. Regards Antoine.
On 1/5/2011 5:43 PM, Antoine Pitrou wrote:
On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedy<tjreedy@udel.edu> wrote:
Thank you for spotting the contradiction; this is now fixed.
I am following your example of looking at checkins. -- Terry Jan Reedy
participants (2)
-
Antoine Pitrou -
Terry Reedy