V Guruprasad wrote:
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.- 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;
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?- reduces the number of context switches going from application to resolver and back;
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.- provides robust kernel multitasking for the resolution process, avoiding buggy or unsafe multithreading in application-based resolvers (like in netscape);
Again, shared libs also reduce duplicate code (though not data; for that you do need the kernel, or a daemon).- reduces the overall code footprint - the filesystem name tree cache is reused, sockaddr_t handling code in applications gone.
--
/===============================================================\
|John Stracke |[EMAIL PROTECTED] |
|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*!|
\===============================================================/
