This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ben.Darnell
Recipients Ben.Darnell, asvetlov, graingert, yselivanov
Date 2022-03-18.16:41:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1647621712.88.0.480890345767.issue46824@roundup.psfhosted.org>
In-reply-to
Content
To summarize the justification, this patch does two things: it moves an optimization from create_connection to getaddrinfo, which makes it apply to more callers (including Tornado), and it makes the code simpler and less redundant (net reduction of 47 non-test lines in the patch). 

As far as we can tell, the reason it wasn't done this way in the first place is that at the time getaddrinfo held a global lock on some platforms, but this is no longer true. If there's still some locking in or around getaddrinfo on some platforms (or some libc implementations), this patch would be a bad idea. Is there a good way to test for that? I suppose we could set up a deliberately-slow DNS server and try to call getaddrinfo with AI_NUMERICHOST while another thread is blocked talking to that server, but that seems like a lot of test infrastructure to build out.
History
Date User Action Args
2022-03-18 16:41:52Ben.Darnellsetrecipients: + Ben.Darnell, asvetlov, yselivanov, graingert
2022-03-18 16:41:52Ben.Darnellsetmessageid: <1647621712.88.0.480890345767.issue46824@roundup.psfhosted.org>
2022-03-18 16:41:52Ben.Darnelllinkissue46824 messages
2022-03-18 16:41:52Ben.Darnellcreate