[Neal Norwitz] > That's what I was thinking of. I thought you had to be accept()ing > prior to connect() working. I thought listen() only sets the # of > outstanding connections allowed (basically internal buffer). But if > the listen() is sufficient, I agree there is no race. listen() "should be" sufficient -- it allocates space for a connection queue, and marks the socket as accepting connections. accept() merely does a blocking "pop" on the queue listen() created. For fun ;-), run it in slow motion, by hand, on that box: open Python in one window, and create a server socket without doing accept(). In another window, try to connect to the first socket's address. The connect should succeed at once. Now socket docs are typically clear as mud, and it's possible that box has a bad implementation. "Thought experiments" can help: if an accept() were necessary before a connection could succeed, why would listen() have a backlog argument at all? Well, if everything else were sane, it wouldn't ;-)
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