Comment 5 for bug 1527636

I haven't looked at the code, but shouldn't this be fixed in the ipAddrToAsciiEnginePrivate class destructor, such that it *doesn't* wait for the thread to exit but somehow leaves an indication that if/when gethostbyaddr() ever returns that it must clean up by itself and exit?

The background thread is there to allow the code to display host names instead of IP addresses where they can be resolved as such, but the API that the class provides still works even if there is no host name. Thus the background thread is there to provide an in-process version of nscd and the problem with it not exiting really ought to be completely hidden from its users. If we can't get it to clean up properly, maybe there should be a way to prevent the thread from being started in the first place, probably controlled by an environment variable. This would only be used in cases where there are IP addresses in use that can't have DNS entries created for them.

In any case I would be happy to see patches for the CAref documentation and the AppDevGuide that explain what's happening when ca_context_destroy() is slow to return.