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 emptysquare
Recipients emptysquare, ned.deily, ronaldoussoren
Date 2016-01-13.19:43:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
An Apple Developer Relations engineer tells me it's "reasonable to assume that getaddrinfo() is thread safe" on OS X 10.5 and later. (He mentioned that iOS inherited the OS X 10.5 DNS architecture, so Apple phones, watches, TVs, hairdryers, etc. can all do concurrent DNS too.)

Before OS X 10.5 the DNS system was a mix of new Mac OS X features, mDNSResponder and Open Directory, along with historical lookupd from NeXT and libresolv from an old BSD. In 10.5 the system was cleaned up to depend on OS X's mDNSResponder consistently; in the process getaddrinfo became thread-safe.

He cites as further evidence of its thread safety:

* The "bugs" section of getaddrinfo's man page was removed in 10.5
* 10.5 is the first OS X to be UNIX '03 certified, which includes the requirement that getaddrinfo be thread-safe
* The system itself uses getaddrinfo extensively as if it's thread-safe
* He hasn't seen reports of thread-safety problems with getaddrinfo

He explained how the code works. In the latest version:

getaddrinfo calls down to libinfo’s "mdns" module:

"mdns" uses the DNS-SD API declared in dns_sd.h, which he says is "well known to be thread safe." The DNS-SD API is part of the mDNSResponder project:

The key function is DNSServiceQueryRecord:

My contact concludes, "As you can see, it does an IPC over to the mDNSResponder process, at which point thread safety is assured."
Date User Action Args
2016-01-13 19:43:42emptysquaresetrecipients: + emptysquare, ronaldoussoren, ned.deily
2016-01-13 19:43:42emptysquaresetmessageid: <>
2016-01-13 19:43:42emptysquarelinkissue25924 messages
2016-01-13 19:43:41emptysquarecreate