[Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py (original) (raw)
Tim Peters tim.peters at gmail.com
Thu Jan 26 03:11:42 CET 2006
- Previous message: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py
- Next message: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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 ;-)
- Previous message: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py
- Next message: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]