V Guruprasad wrote: >- eliminates sockaddr_t handling in the user space, allowing > application code to become free of IPv4/IPv6 (or for that matter > raw Ethernet or ATM) dependencies; > Doesn't using a shared library for the resolver give you the same benefit? It's in user space, but it's not in the app. >- reduces the number of context switches going from application > to resolver and back; > Do you have data showing these context switches are a problem? To me, it seems like you're optimizing something that doesn't take up that much time anyway--what apps spend that much CPU time on DNS lookups? >- provides robust kernel multitasking for the resolution process, > avoiding buggy or unsafe multithreading in application-based > resolvers (like in netscape); > Again, the same thing can be done with a good shared lib. Most current Unices include gethostbyname_r(), which is thread-safe. Netscape just started too early, when threading support in the OS was still pretty uneven. >- reduces the overall code footprint - the filesystem name tree > cache is reused, sockaddr_t handling code in applications gone. > Again, shared libs also reduce duplicate code (though not data; for that you do need the kernel, or a daemon). -- /===============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/