Date: Thu, 19 Jun 2003 00:42:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Xu <davidxu@viatech.com.cn> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Removal of bogus gethostbyaddr_r() Message-ID: <3EF1697D.635165E5@mindspring.com> References: <Pine.GSO.4.10.10306181413010.16088-100000@pcnet5.pcnet.com> <001e01c335e6$1ccca630$0701a8c0@tiger>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > > > It lies? (_r). > > > > If that's true, then it's a bug and eventually should > > be fixed. Additionally, you can't go around removing > > public interfaces without bumping library versions > > (unless said interface hasn't seen a release yet). > > I think those *_r interfaces are not very useful except > bloating library. why do not improve non _r version to use > thread local instead to make them reentrant between threads ? Nameserver services are incredibly problematic to make thread safe. For example, you can't serialize responses, and you have to support both UDP, and, if the UDP response claims that the request was too large, you have to connect using TCP, and disconnect, etc.. As one example, suppose you have two requests outstanding, one for "A.COM" and the other for "C.NET", and you get a response from one that claims to be authoritative for the other, thus poisinging your outstanding response list? The net effect is that you are running a DNS proxy cache, with unrolled loop, in your *_r() routines, and you have to do everything a proxy cache would do on behalf of its clients. The problem with your approach here is that things like sockets aren't thread-local. It wouldn't make much sense for a multithreaded Apache to have a UDP socket per thread before it's allowed to use DNS services. One approach to resolving the issue would be to serialize the access to a request queue, and throw off some number of threads in order to handle library consumer responses, each with its own context statite (doesn't matter if if's thread local storage, or just an array of structures indexed by start order and parameter, or using a set of auto's allocated in the thread main, of the stack, which is also thread local, by definition), which would include a separate UDP socket. Doing this has a problem, though, in that you now require threads to use the interface, even if your program's a finite state automaton with multiple concurrent contexts, but no threads: you can't have an unthreaded program. The upshot of all this is that there's going to be a lot of work involved no matter how you slice it (the best suggestion so far, the last time this question came up, is to use some sort of "lookupd", similar to Apple's Darwin, and make the messaging interface thread safe and the lookupd a smart DNS proxy server). Predominant wisdom has been to let the Bind people solve this for us, when they release their Bind-9 resolver library release version (what there is of the current stuff is beta). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF1697D.635165E5>