Date: Fri, 02 Aug 2002 01:23:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Hajimu UMEMOTO <ume@mahoroba.org> Cc: Mikhail Teterin <mi+kde@aldan.algebra.com>, arch@FreeBSD.ORG Subject: Decrepit resolver library Message-ID: <3D4A416C.D1FAD950@mindspring.com> References: <200207311641.g6VGfRWj099655@freefall.freebsd.org> <200208011830.20096.mi%2Bmx@aldan.algebra.com> <3D49BBEF.F1156C79@mindspring.com> <200208012006.25130@aldan> <3D49E41D.57DBF81C@mindspring.com> <ygeu1mdq3m6.wl@cheer.mahoroba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hajimu UMEMOTO wrote: > tlambert2> I'll complain about resolver being in libc, if that'll make > tlambert2> you happy... it'll make everyone who has to do name lookups > tlambert2> serially so they compalin about IPv6 in Mozilla happy... 8-). > > No, it doesn't help for Mozilla. Mozilla does separate lookups for A > RR and AAAA RR. To make happy with Mozilla, someone needs to rewrite > Mozilla. Actually, you would expect the resolver to resolve the name in parallel for all the protocols it understands, and then return "the best one", whatever that is, instead. If that happens to be IPv6, then you get a sockaddr * for IPv6; if it's IPv4, you get one for IPv4; if it's AppleTalk, you get that. All the application should know is that it gets a sockaddr * and a protocol family variable back from the resolver. Of course, with the resolver people pointing fingers at the Mozilla people, even when the problem they are trying to solve is the inability of the resolver to perform concurrent lookups simultaneously, it will always look like it's someone else's problem. And no, making the application use threads to get around the resolver libraries serialization problems isn't a fix, it's a workaround that shouldn't be necessary. But if "threads" is the only answer that will be permitted, then it seems that the resolver belongs some place other than libc, anyway (at least libc_r, but preferrable a seperate library). The current tight coupling is a result of the inability to use libraries lineked to other libraries to work around the historical association issue. Of course that neglects the fact that the ELF standard doesn't really condone static libraries in the first place... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4A416C.D1FAD950>