2012/3/22 Mason <[email protected]> wrote: > Yang Tse wrote: > >> Do you have a system on which current git version detection of >> getaddrinfo() thread-safeness is wrong? > > It doesn't work with lwip, where, in the typical configuration, > > 1) gethostbyname is not thread-safe > 2) getaddrinfo is thread-safe (AFAICT) > 3) netdb.h declares extern int h_errno; (as permitted by POSIX)
Given that current LWIP git version [1] lwip_getaddrinfo() implementation is using atoi() and that lwip_getaddrinfo() header does not state that it is thread safe, and given that [1] lwip_gethostbyname_r() header comment states that "Thread-safe variant of lwip_gethostbyname: instead of using a static buffer, this function takes buffer and errno pointers as arguments and uses these for the result." I can only conclude that: lwip_getaddrinfo() is not thread-safe and that lwip_gethostbyname_r() is thtread-safe. IOW libcurl should use lwip_gethostbyname_r(), avoid lwip_getaddrinfo(), and by no means define HAVE_GETADDRINFO_THREADSAFE when using LWIP stack. This will hold true until in some future LWIP developers document that lwip_getaddrinfo() is thread-safe, removes usage of atoi() and replaces usage of netconn_gethostbyname() with lwip_gethostbyname_r() in lwip_getaddrinfo(). >> Not theoretical thinking but actual run and facts. > > I'm sorry you don't like to hear it, but checking for h_errno > to decide whether getaddrinfo is thread-safe is misguided. > Just because it works for glibc(*) doesn't change that fact. > > (*) # define h_errno (*__h_errno_location ()) I'm not saying that existing check is perfect. I was asking you for the specific case you were suposedly suffering a wrong result. And I say 'suposedly' because the check result is appropriate when using LWIP. > The problem with h_errno is that it is tied to obsolete functions. > There is no connection whatsoever between h_errno and getaddrinfo. Just because someone compiles LWIP current git version with _POSIX_C_SOURCE defined to 200809L does not make lwip_getaddrinfo() thread safe nor does it modify h_errno usage/requirements. > I'll take a look at the getaddrinfo code in FreeBSD 4 to understand > why libcurl declare this implementation not thread-safe. Do you know, > off-hand? Implementation of getaddrinfo() in FreeBSD 5.4 and older versions is not thread-safe [2]. FreeBSD 5.5 and newer versions have a thread-safe getaddrinfo(). >> Obviously if you have a system on which detection is wrong, I'm >> interested in further details about that platform. > > With the lwip port, libcurl picks gethostbyname. I suppose I can > live with it for now, but since gethostbyname has been zapped by > POSIX since 2008, it might disappear from lwip some day. > > I meant libcurl picks gethostbyname_r (and I don't know if > gethostbyname_r would disappear along with gethostbyname). Up to now lwip_gethostbyname_r() is the right choice and not defining HAVE_GETADDRINFO_THREADSAFE the proper result for the getaddrinfo() thread-safeness check when using LWIP. If in any future things change we'll adapt as required when the moment arrives. [1] http://git.savannah.gnu.org/gitweb/?p=lwip.git;a=blob;f=src/api/netdb.c;h=6a4bac561ce65ee0f599608705cdaae5174ef93e;hb=HEAD [2] http://www.freebsd.org/cgi/man.cgi?query=getaddrinfo&sektion=3&manpath=FreeBSD+5.4-RELEASE -- -=[Yang]=- ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
