Just wondering: Why is getaddrinfo breaking POSIX by not being thread-
safe and what is the thread-safe alternative to it? (Please don't tell
me to use locks, as that would kill the possibility to lookup multiple
hosts at once).
I consider it very strange that an OS still has a thread-unsafe
getaddrinfo in the year 2009, even though POSIX and RFC 2553 both
require it to be thread-safe. And it makes it especially hard to write
portable applications, as there is no way to check if getaddrinfo is
thread-safe in a configure script.
Nobody did the work yet. If it's very important to you, consider
spending effort making it thread safe. I believe netbsd and freebsd
have thread safe implementations. But actullay verifying that is
Wouldn't it be possible to at least put a lock around it, so that at
least it does not produce bogus lookups, but is does sequentiel but
correct lookups instead? This would at least not break POSIX and would
be compatible to thread-safe implementations, though slower than
thread-safe implementations. It would already be a big relieve for
programmers if they can just use getaddrinfo and know that they at
least get a correct result on any OS. ATM, I have to do a whitelist of
operating systems that are known to have thread-safe implementations
and do a lock for the others.
Yes, the NetBSD implementation is thread-safe since 4.0. For FreeBSD,
I don't know since which version it is thread-safe, but it's thread-
safe in recent versions.
For the verifying part: If the implementation has no side-effects
(like modifying some global variable that is not per-thread), the
implementation is thread-safe.
Thank you for your lesson. We're lucky we have a very helpful community.
I still hope that this mailing thread has the nice side-effect of
getting us a verified thread-safe getaddrinfo implementation.