Allow for more flexible control of connection backlog and number of connections accepted "at once" #3062
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR proposes a form for increased flexibility in a) controlling the backlog size for the listening connection(s) a Tornado application ends up using, and b) controlling how many connections are accepted during one iteration of Tornado's I/O loop, something that currently is inherently tied to the default backlog size (hence both changes with a single commit).
Tornado applications can admittedly already effectively control the backlog size applied to their listening socket(s). They may do so through
a) importing and altering the value of the(can't do so because default function arguments are assigned during function creation, not invocation), or b) resorting to initializing their listening sockets differently than what the example in the user guide illustrates, e.g. invoking_DEFAULT_BACKLOG
module variable fromnetutil
bind
oneself.The second option has two drawbacks. First, it necessitates changing the "simple" application initialization code to a more involved one just to be able to specify own backlog. Second, by changing the code thus, the application will have to resolve and bind each socket itself -- something Tornado otherwise would have done for it "for free" with its very useful
bind_sockets
. Of coursebind_sockets
is also part of the API, and may be called as well, but that turns the code into an even more involved variant for initialization.The first option does not have the aforementioned drawbacks, of course -- the application can be initialized as per the "simple" example in the user guide, having set the imported_DEFAULT_BACKLOG
to a value application prefers by default.More importantly, however, both options make it impossible to have Tornado not specify any backlog argument to
listen
at all. These proposed changes partially aim at alleviating that limitation. Thing is, a future version of Python is free to change how the "default reasonable value" is chosen forlisten
, and Tornado, being a framework of increasing adoption, in an increasingly varied number of scenarios, may do well by allowing applications to defer to said default behaviour by Python, instead of insisting on a "magic" number of its own.So this PR proposes to first and foremost change the default backlog size to
None
, allowing Tornado to be able to correspondingly omit providing backlog argument tolisten
and thus defer to a backlog as decided by Python. Of course, specifying an integer value means the value will be passed tolisten
, as before.Additionally, due to the default backlog size now potentially being
None
, the number of connections attempted accepted at one time can no longer simply follow the default backlog size as before. We use this opportunity to add an additional module variable which may be used to control the number [of connections to try and accept], deferring (ifNone
) to default backlog size if the latter is non-zero, or ultimately, 128 (a final fallback for lack of a better magic value).There is a prior conversation touching on this topic.