> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4