From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Async DNS lookups Date: Tue, 2 Nov 2010 12:15:10 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1288715174 31630 80.91.229.12 (2 Nov 2010 16:26:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Nov 2010 16:26:14 +0000 (UTC) To: Emacs Developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 02 17:26:09 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PDJgT-00016y-J9 for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 17:26:05 +0100 Original-Received: from localhost ([127.0.0.1]:53236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDJgS-0000og-Ll for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 12:26:04 -0400 Original-Received: from [140.186.70.92] (port=59969 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDJWB-00016d-Gv for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:15:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDJWA-0006O5-5C for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:15:27 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:53614 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDJW2-0006MI-Dy for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:15:26 -0400 Original-Received: from squish.hsd1.ma.comcast.net (c-98-216-239-22.hsd1.ma.comcast.net [98.216.239.22]) by raeburn.org (8.14.3/8.14.1) with ESMTP id oA2GFGKd006261; Tue, 2 Nov 2010 12:15:16 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1081) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132278 Archived-At: On Nov 1, 2010, at 12:09, Tom Tromey wrote: > A couple other approaches come to mind as well. >=20 > You could run the synchronous resolver in a new thread, and have the > main thread run the event loop. >=20 > You could use a small helper program instead of calling the resolver > in-process. That is basically the same as the previous idea, > substituting a process for a thread. These would have the advantage that, rather than interacting with DNS = directly, you can call getaddrinfo and use /etc/hosts or anything else = configured by nsswitch or equivalent. Assuming that all name-resolution = calls should go straight to DNS (when you're not specifically looking = for non-A/AAAA/PTR data) would be incorrect.... I think getaddrinfo_a looks nice, but I'd rather not use it unless we = also have a workaround for non-glibc systems. Presumably that would use = your basic "spin off a thread that blocks in getaddrinfo and invokes a = callback when done" approach, which (according to the blog Tom pointed = to) is all getaddrinfo_a does anyways. Maybe that means the code could = be borrowed; maybe that means we should just implement the latter and = not bother with getaddrinfo_a. Ken=