From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Sun, 21 Feb 2016 11:29:12 +0100 Message-ID: <86twl22w7b.fsf@realize.ch> References: <87y4b393hl.fsf@gnus.org> <83io27ytu3.fsf@gnu.org> <87k2mmzkry.fsf@gnus.org> <83k2mlyet8.fsf@gnu.org> <87lh71nriy.fsf@gnus.org> <8637t8opla.fsf@realize.ch> <871t8skg6c.fsf@gnus.org> <86y4b0n5q2.fsf@realize.ch> <87fux7gb7o.fsf@gnus.org> <83wpqjvd2f.fsf@gnu.org> <87zivfobn4.fsf@gnus.org> <86y4ao5g1c.fsf@realize.ch> <87r3ggdo9f.fsf@gnus.org> <86twlb5yl4.fsf@realize.ch> <83d1rzz1mu.fsf@gnu.org> <86egcc49qu.fsf@realize.ch> <87io1k41cg.fsf@gnus.org> <56C8A89C.4020909@cs.ucla.edu> <861t873zlj.fsf@realize.ch> <56C8CD9D.1020504@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1456050614 15430 80.91.229.3 (21 Feb 2016 10:30:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Feb 2016 10:30:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 21 11:30:10 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 1aXRHF-0003ic-85 for ged-emacs-devel@m.gmane.org; Sun, 21 Feb 2016 11:30:09 +0100 Original-Received: from localhost ([::1]:39793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXRHB-0000ZY-AY for ged-emacs-devel@m.gmane.org; Sun, 21 Feb 2016 05:30:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXRGy-0000Yq-Dr for emacs-devel@gnu.org; Sun, 21 Feb 2016 05:29:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXRGv-0001SL-8Q for emacs-devel@gnu.org; Sun, 21 Feb 2016 05:29:52 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:1047) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aXRGu-0001SD-Oy for emacs-devel@gnu.org; Sun, 21 Feb 2016 05:29:49 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Sun, 21 Feb 2016 11:29:42 +0100 Original-Received: from MYNGB (192.168.66.64) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Sun, 21 Feb 2016 11:29:15 +0100 In-Reply-To: <56C8CD9D.1020504@cs.ucla.edu> (Paul Eggert's message of "Sat, 20 Feb 2016 12:33:33 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 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:200371 Archived-At: Paul Eggert writes: > Alain Schneble wrote: >> But the async-dns implementation that Lars provided uses another >> approach instead: it polls by calling gai_error (succeed, failed, in >> progress, ...) repeatedly from wait_reading_process_output. > > You're ahead of me, since I haven't read the implementation. From what > you say, it appears that Emacs needs to cancel DNS requests that it > thinks are so old that the answer is not likely to be > useful. Presumably this could be done just before calling gai_error, > by calling gai_cancel on the old requests. That's a good point. Calling delete-process on a process with a pending DNS request is the only situation so far where we explicitly cancel the pending request using gai_cancel. But I don't think we have to care about timing out DNS requests on our own. That should already be handled by the synchronous getaddrinfo that gets called in the worker threads of getaddrinfo_a. It should be safe to assume that the timeouts that getaddrinfo uses were chosen wisely, I think. To me, there seems to be no need to introduce yet another timeout on "our" level. ...and the behavior with the recent patch looks promising :)