Martin: >I think that part is already settled: getaddrinfo, on Linux, is >thread-safe. The latest Posix/Single UNIX spec in fact require getaddrinfo (and getnameinfo) to be thread-safe. and Guido: >I tried to read the glibc getaddrinfo() source, but it looks like it >would be a term project... It could be that it's just doing a lot >more interaction with a DNS server. > >I believe that Jeremy suspects that the test program isn't just slow, >but that one slow thread actually blocks all other threads from making >progress. If that's the case (we don't know for sure), we're looking >for a bottleneck in the getaddrinfo() code that somehow holds a >resource needed by all threads calling getaddrinfo(). Gives me a headache, too, especially once it vectors off into the glibc nss code. These routines (__gethostbyname2_r is the likely suspect, __gethostbyaddr_r and __getservbyname_r might also get called) do have paths that could twiddle a glibc internal lock so it's not impossible there's an issue here, although at something less than a term-paper-depth look it doesn't SEEM like it should ever be able to block for very long.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4