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
