[issue11721] socket.accept() with a timout socket creates bogus socket

Changes by Kristján Valur Jónsson : -- resolution: -> duplicate status: open -> closed superseder: -> On Mac / BSD sockets returned by accept inherit the parent's FD flags ___ Python tracker

[issue11721] socket.accept() with a timout socket creates bogus socket

Antoine Pitrou added the comment: > The corresponding defect has a long (and bothersome) discussion. I am, > however, surprised that this was not considered a "bug" and backported. I think Martin's argument was that it could break compatibility. > I can agree with the fix (my number 1 sugges

[issue11721] socket.accept() with a timout socket creates bogus socket

Kristján Valur Jónsson added the comment: I cannot see from the link to which branch that was committed, or what revision. But I assume it is the default branch. I can confirm that this appears to be fixed. The corresponding defect has a long (and bothersome) discussion. I am, however, su

[issue11721] socket.accept() with a timout socket creates bogus socket

Antoine Pitrou added the comment: > In short: If you have a socket with settimeout(1), then accept a > connection on it, the new socket will have gettimeout()==None, but its > state will still (internally) be non-blocking. The attached script > demonstrates the issue. This should have been f

[issue11721] socket.accept() with a timout socket creates bogus socket

Changes by Kristján Valur Jónsson : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue11721] socket.accept() with a timout socket creates bogus socket

New submission from Kristján Valur Jónsson : I found this defect at PyCon 2011 after spending a lot of type fidgeting with ssl. The test_ssl.py unittest was using timeout on accept sockets and it was working fine there, but not with the code I was working out. Turns out that _ssl.py resets t