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(_at_)centivinc(_dot_)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*!|
\===============================================================/