2012/3/22 Mason <mpeg.blue_at_free.fr> 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