From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Sat, 23 Jan 2016 22:56:38 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143d888f61c9a052a018a0a X-Trace: ger.gmane.org 1453561014 22046 80.91.229.3 (23 Jan 2016 14:56:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Jan 2016 14:56:54 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 23 15:56:54 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aMzcT-0007xk-3E for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2016 15:56:53 +0100 Original-Received: from localhost ([::1]:57686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMzcS-0005EZ-3x for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2016 09:56:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMzcK-0005EM-Kv for emacs-devel@gnu.org; Sat, 23 Jan 2016 09:56:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMzcF-0004h6-Hy for emacs-devel@gnu.org; Sat, 23 Jan 2016 09:56:44 -0500 Original-Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]:36116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMzcF-0004h2-Bc for emacs-devel@gnu.org; Sat, 23 Jan 2016 09:56:39 -0500 Original-Received: by mail-vk0-x231.google.com with SMTP id n1so55024234vkb.3 for ; Sat, 23 Jan 2016 06:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SGizV3y4YAFz4ViCqY5NOHFAeVBJn32+oVE7fzOHkII=; b=PrDfFNPnuAtVDpo/XhwghXW3vb4QNu+8bTzJC0S0Y/8EMCivYKvJnDdesyfftv9AWe GCaAEMiQLOIj7+kkzSPcQTUYzCvnFnqTWTzFmsydrSpi1/mHaj/32G72oVeeh9VQtz71 QP72/o7FhrcJVvhNebK2JRvzQYK4JeWruooVddU4fnM99xMWYP5UKJSceDXE9TYbrdJ3 6seKMyyvDrqqdZcucnAENhPoGj98Lif7gFcSEZHC6pye3E7rh/XN6ICDIc38NqspI8hj VfIdXHRCChjspMfa1D+hIarppoMx6nJlaI9rH4bEB9qVy2HC3JngZcN4WE8S2othLhy6 lAvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SGizV3y4YAFz4ViCqY5NOHFAeVBJn32+oVE7fzOHkII=; b=amc0biJig36iy35m4IfSODJbelLcHyhsnR3QG0FCe5xpfMOgWvChbmUSFkBZMznY93 IStPPcAUSnEY45w7C8KMVbvvcrl8ZJL5LFNA2kKlY4tBxv8otbDUXKQJswxhWUiOz37M Fi6ty16FLS3uEaC1VJWypNrpXTsLMGsXasPOPonok3mVXP4U9mgzlKJf2Q53dR8DtFHQ YfA+7nAhFlLfdt6sxM4wsXBq9pOumiDoSxEP9BVd0wMuCEHLxw4GcrsTK9O8hOjldSl+ v9/Zj7fdLLsF00XRmT0X4xcdqLTpSRm5fevvCc1w17pWv5Ivra12rGo2ndeLGxWXvw5t zf+w== X-Gm-Message-State: AG10YOSgwi9oH8xCEEnQa5lrg23E22tEoscbdkqDlkD+AOCRdpDF4awlwZrnEddTKgZoD0mFFWXP6jPaF8F2YQ== X-Received: by 10.31.5.139 with SMTP id 133mr5536369vkf.157.1453560998269; Sat, 23 Jan 2016 06:56:38 -0800 (PST) Original-Received: by 10.103.48.2 with HTTP; Sat, 23 Jan 2016 06:56:38 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198645 Archived-At: --001a1143d888f61c9a052a018a0a Content-Type: text/plain; charset=UTF-8 On 23 January 2016 at 21:50, Lars Magne Ingebrigtsen wrote: > I see four ways of implementing an async name resolution function: > > 1) Add a new `resolve-name' function that would fork Emacs, call > getaddrinfo/gethostbyname, and do a callback once we get a reply. The > problem is that a forked Emacs is a very strange thing, and is not > something we otherwise do. I looked at this for a day last time, and I > couldn't get it to work, really. Perhaps somebody else could, though. > > 2) Use one of the newer async C resolver libraries. This would not be > available on all platforms, and would be Yet Another Dependency which > I'm sure everybody would rather that we avoid. > > 3) Create a tiny helper program in lib-src that would read names from > stdin and output resolves on stdout. It would use > getaddrinfo/gethostbyname, and could very well be multithreaded, so that > it could do name resolution on parallel. > > 4) Pick the data out of res_init to find the DNS servers, and then just > use dns.el for name resolution. This would be trivial to implement, but > may not respect the name resolutions settings on some operating systems. > This is something I have been wondering for a while, and I think that this may be as good a time as any to ask the question. Are there any technical reasons why the name resolution (or whatever it is that needs to be asynchronous) could not be run in a thread in the Emacs process itself? As long as the thread is not running any Lisp code, it should work, correct? I'm asking this because I've had some ideas on modules that I would write once the loadable module support in Emacs is complete, and in some cases I want to be able to do stuff in threads. Regards, Elias --001a1143d888f61c9a052a018a0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 3 January 2016 at 21:50, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
=C2=A0
I see four way= s of implementing an async name resolution function:

1) Add a new `resolve-name' function that would fork Emacs, call
getaddrinfo/gethostbyname, and do a callback once we get a reply.=C2=A0 The=
problem is that a forked Emacs is a very strange thing, and is not
something we otherwise do.=C2=A0 I looked at this for a day last time, and = I
couldn't get it to work, really.=C2=A0 Perhaps somebody else could, tho= ugh.

2) Use one of the newer async C resolver libraries.=C2=A0 This would not be=
available on all platforms, and would be Yet Another Dependency which
I'm sure everybody would rather that we avoid.

3) Create a tiny helper program in lib-src that would read names from
stdin and output resolves on stdout.=C2=A0 It would use
getaddrinfo/gethostbyname, and could very well be multithreaded, so that it could do name resolution on parallel.

4) Pick the data out of res_init to find the DNS servers, and then just
use dns.el for name resolution.=C2=A0 This would be trivial to implement, b= ut
may not respect the name resolutions settings on some operating systems.

This is something I have been wondering f= or a while, and I think that this may be
as good a time as any to= ask the question.

Are there any technical reasons= why the name resolution (or whatever it is that
needs to be asyn= chronous) could not be run in a thread in the Emacs process
itsel= f? As long as the thread is not running any Lisp code, it should work, corr= ect?

I'm asking this because I've had some= ideas on modules that I would write once
the loadable module sup= port in Emacs is complete, and in some cases I want
to be able to= do stuff in threads.

Regards,
Elias
--001a1143d888f61c9a052a018a0a--