Message258125
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. |
|
Date |
User |
Action |
Args |
2016-01-13 01:51:28 | emptysquare | set | recipients:
+ emptysquare, ronaldoussoren, ned.deily |
2016-01-13 01:51:28 | emptysquare | set | messageid: <1452649888.4.0.148094104569.issue25924@psf.upfronthosting.co.za> |
2016-01-13 01:51:28 | emptysquare | link | issue25924 messages |
2016-01-13 01:51:27 | emptysquare | create | |
|