From owner-freebsd-arch Fri Aug 2 1:24:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF25637B400 for ; Fri, 2 Aug 2002 01:24:11 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75BA243E3B for ; Fri, 2 Aug 2002 01:24:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0128.cvx22-bradley.dialup.earthlink.net ([209.179.198.128] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17aXj5-0004ZD-00; Fri, 02 Aug 2002 01:23:59 -0700 Message-ID: <3D4A416C.D1FAD950@mindspring.com> Date: Fri, 02 Aug 2002 01:23:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO Cc: Mikhail Teterin , arch@FreeBSD.ORG Subject: Decrepit resolver library References: <200207311641.g6VGfRWj099655@freefall.freebsd.org> <200208011830.20096.mi+mx@aldan.algebra.com> <3D49BBEF.F1156C79@mindspring.com> <200208012006.25130@aldan> <3D49E41D.57DBF81C@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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