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.01:51:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1452649888.4.0.148094104569.issue25924@psf.upfronthosting.co.za>
In-reply-to
Content
NetBSD has a concurrency test for getaddrinfo, so I tried it on Mac to see if getaddrinfo is thread-safe here, too. It appears that it is thread-safe.

I copied NetBSD's getaddrinfo concurrency test "h_resolv.c" and the test's data file "d_mach" from src/tests/lib/libpthread in the NetBSD 7 source:

http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libpthread/

I've also attached these files to this ticket.*

The test program h_resolv.c compiles fine on Mac OS X 10.10 with clang 7, and the test passes using the same parameters that the NetBSD test uses, resolving five host names on five threads:

./h_resolv -d -n 5 -h 5 d_mach

There's even evidence that getaddrinfo is actually concurrent on my Mac: resolving 100 hostnames on 1 thread takes about 6 seconds, but using 100 threads take only 3 seconds. To test concurrency I ran this:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 100 -n 1 d_mach

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 1 -n 100 d_mach

Those sudo commands flush the Mac's DNS cache between runs.

* I removed one unresolvable domain, "cnftp.bjpu.edu.cn", from the test file d_mach. That domain took 15 seconds to time out and made the rest of the timing irrelevant.
History
Date User Action Args
2016-01-13 01:51:28emptysquaresetrecipients: + emptysquare, ronaldoussoren, ned.deily
2016-01-13 01:51:28emptysquaresetmessageid: <1452649888.4.0.148094104569.issue25924@psf.upfronthosting.co.za>
2016-01-13 01:51:28emptysquarelinkissue25924 messages
2016-01-13 01:51:27emptysquarecreate