2009/11/13, Jamie Lokier wrote:

> > Take for example systems that expose all four getaddrinfo,
> > gethostbyname, getaddrinfo_r and gethostbyname_r, when this happens
> > the non *_r functions might not be threadsafe while the *_r ones are
> > granted to be so.
>
> There is no need for getaddrinfo_r, because getaddrinfo is *already*
> defined as a thread-safe, reentrant interface.

He,he! Answering posts when in a hurry is something I should learn not
to do. Disregard I've ever written that getaddrinfo_r thingy. Another
dumb sentence for history!!

> From a thread-safety point of view, getaddrinfo is like
> gethostbyname_r, not like gethostbyname.

Of course.

> The only problem with getaddrinfo is that some people implemented it
> as a wrapper around gethostbyname, or around other DNS functions,
> without using a lock to make that thread safe. (And some people did
> use a lock, which makes it thread safe but not concurrent. Oh well!)

And others had thread safe versions which leaked memory when cancelled
asynchronously. All this might open some cans of worms.

> As far as I know, nobody has ever implemented gethostbyname_r as a
> stupid thread-unsafe wrapper around gethostbyname. After all, what
> would be the point in that?

> That's why the presence of gethostbyname_r could be a clue that the
> resolver implementation is thread safe, or can be used that way,

I partially agree with that. I would be a bit more picky and say that
the resolver implementation is thread safe when used through the
gethostbyname_r interface.

> and so getaddrinfo is likely to be thread safe to.

Not necessarily true. But since you say 'likely', you admit the
possibility of not happening.

> Even if getaddrinfo is a wrapper, it is likely to be wrapping
> around gethostbyname_r in that case.

Two concatenated 'likely's reduce the likelihood.

:-)

> I don't know if presence of gethostbyname_r really means getaddrinfo
> is thread-safe, but it's a good idea.

I haven't said it was a bad idea. I said that I would prefer not to
infer the capabilities of one function based on the capabilities or
existence of a second one for configure tests. No more.

It would be nice if we could actually test if getaddrinfo is thread
safe or not in the configure script. But we can not do that kind of
tests in the configure script, some times it would hang forever,
others it would crash, and others would finish nicely when getaddrinfo
is actually thread safe.

So we must fall back to simpler tests and some hard-coded knowledge in
order to provide a reasonable answer.

And here is the meat of the getaddrinfo thread safe capability test.

Do we want to avoid false positives or false negatives?

If the test result says that getaddrinfo is thread safe, and it
happens not to be, the result will be that libcurl will fail when
used.

On the other hand, if the test result says that getaddrinfo is not
thread safe, when it actually is, what will happen is that hostip.c
will (or should) handle everything nicely and libcurl will not fail.
It will incur in some performance penalty relative to that achieved if
no false negative result was involved, but that should be all.

Those are my reasons for preferring a false negative over a false
positive. And in consequence not wanting to say that getaddrinfo is
thread safe because of the existence of gethostbyname_r.

And that was the reason for current incarnation of the getaddrinfo
thread safeness check. Which only says that getaddrinfo is thread safe
on those systems for which it has the necessary hard-coded knowledge
to say so.

But, I also see that this is a big pain as it would force us to add
hard-coded knowledge for every single system with a thread safe
getaddrinfo. (argh! nobody wants this work).

So, what's next?

Admit that to make this maintainable some false positive, saying that
getaddrinfo is thread safe when it isn't, will happen at some point
with some system. and that most likely it will go unnoticed until
libcurl is deployed.

For the configure script...

if getaddrinfo exists then
  assume that it is thread safe;
  if OS version known to have a thread unsafe getaddrinfo then
   check result will be that it is not thread safe
  else if h_errno is not defined as a preprocessor symbol then
   check result will be that it is not thread safe
  fi
fi

OK to this? Costa, Daniel, Jamie, Joshua?

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html