Having to pass an explicit backlog value to listen() is a pain: most people don't know which value to pass, and often end up using a value too small which can lead to connections being rejected.For example, if you search throughout the standard library, you'll see many different hard-coded values.The patch attached uses a default value of SOMAXCONN for socket.listen(): it should give a good default behavior (that's what golang does for example: in fact they go even further by checking the runtime value from net.core.somaxconn).A second step would be to update the codebase to remove explicit backlogs (unless specific case).

Is there a risk of SOMAXCONN being huge and therefore allocating a large amount of resources?

> Is there a risk of SOMAXCONN being huge and therefore allocating a large amount of resources?On a sensible operating system, no, but better safe than sorry: thepatch attached caps the value to 128 (a common SOMAXCONN value).It should be high enough to avoid connection drops in commonworkloads, and still guard against non-sensical SOMAXCONN values.

Any objection to the last version?If not, I'll commit it within a few days.

Looks good to me!

> Py_MIN(SOMAXCONN, 128)On Windows, it's not the best choice to use this hardcoded limit. socket.SOMAXCONN is 2^31-1.listen() documentation says that Windows chooses a reasonable backlog value for you if you pass SOMAXCONN:http://msdn.microsoft.com/en-us/library/windows/desktop/ms739168%28v=vs.85%29.aspxYou should maybe use SOMAXCONN by default on Windows, and Py_MIN(SOMAXCONN, 128) by default on other platforms (UNIX).

An article suggests to use max(1024, socket.SOMAXCONN) (to "listen() backlog as large as possible") instead of socket.SOMAXCONN because the OS maximum can be larger than SOMAXCONN (and that it's not possible in Python to get the OS value):http://utcc.utoronto.ca/~cks/space/blog/python/AvoidSOMAXCONN?showcomments#commentsThe following article tries to explain why the default limit is 128 on Linux:https://derrickpetzold.com/p/somaxconn/Article giving the value chosen by Windows when SOMAXCONN is passed: it depends on the Windows version (between 5 and 50, hard limit of 200 on Windows 7):http://stackoverflow.com/questions/4709756/listen-maximum-queue-size-per-windows-version

>> Py_MIN(SOMAXCONN, 128)>> On Windows, it's not the best choice to use this hardcoded limit. socket.SOMAXCONN is 2^31-1.I don't see what this would bring: 128 *is* a reasonable limit.> listen() documentation says that Windows chooses a reasonable backlog value for you if you pass SOMAXCONN:>http://msdn.microsoft.com/en-us/library/windows/desktop/ms739168%28v=vs.85%29.aspx>> You should maybe use SOMAXCONN by default on Windows, and Py_MIN(SOMAXCONN, 128) by default on other platforms (UNIX).Trying to come up with a good heuristic is a lost battle, since itdepends not only on the OS but also the application.  The goal is tohave a default value that works, is large enough to avoid connectiondrops in common use cases, and not too large to avoid resourceconsumption.> An article suggests to use max(1024, socket.SOMAXCONN) (to "listen() backlog as large as possible")> instead of socket.SOMAXCONN because the OS maximum can be larger than SOMAXCONN (and that> it's not possible in Python to get the OS value):In theory we could use net.core.somaxconn sysctl & Co (that's what godoes), but IMO it's overkill.

Hum ok, thanks for your explanation Charles-François. socket_listen-1.diff looks good to me.

New changeset09371221e59d by Charles-François Natali in branch 'default':Issue#21455: Add a default backlog to socket.listen().http://hg.python.org/cpython/rev/09371221e59d

Committed, thanks!