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: Thu, 4 Feb 2016 09:18:57 +0100 Message-ID: <8637t8opla.fsf@realize.ch> References: <87si1gx6wz.fsf@gnus.org> <86y4b5zvzt.fsf@gmail.com> <8760y9kwrk.fsf@gnus.org> <87wpqpjgwy.fsf@gnus.org> <83a8nk1cxk.fsf@gnu.org> <87h9hrnc8x.fsf@gnus.org> <83powfzsqt.fsf@gnu.org> <87y4b393hl.fsf@gnus.org> <83io27ytu3.fsf@gnu.org> <87k2mmzkry.fsf@gnus.org> <83k2mlyet8.fsf@gnu.org> <87lh71nriy.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454573996 12306 80.91.229.3 (4 Feb 2016 08:19:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 08:19:56 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 04 09:19:56 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 1aRF8t-0002X3-A6 for ged-emacs-devel@m.gmane.org; Thu, 04 Feb 2016 09:19:55 +0100 Original-Received: from localhost ([::1]:40185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRF8n-0002eI-FB for ged-emacs-devel@m.gmane.org; Thu, 04 Feb 2016 03:19:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRF8g-0002ca-2Q for emacs-devel@gnu.org; Thu, 04 Feb 2016 03:19:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRF8c-0003qW-Bd for emacs-devel@gnu.org; Thu, 04 Feb 2016 03:19:41 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3324) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aRF8X-0003pg-IK; Thu, 04 Feb 2016 03:19:33 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Thu, 4 Feb 2016 09:19:19 +0100 Original-Received: from MYNGB (192.168.250.224) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 4 Feb 2016 09:18:58 +0100 In-Reply-To: <87lh71nriy.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 04 Feb 2016 13:22:29 +1100") 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:199285 Archived-At: Lars Ingebrigtsen writes: > Eli Zaretskii writes: > >> If we introduce such a thread, its code needs to be carefully audited >> for the above-mentioned gotchas. E.g., passing to it a C pointer to a >> contents of a Lisp string is probably unsafe. It's not rocket science >> to DTRT in this case (we already do that quite a lot on MS-Windows), >> it just requires very careful programming and code review. > > Sure. But I think that for the getaddrinfo_a thing, it really is that > simple. Everything is allocated and freed in the main thread, the > address lookup doesn't need to access anything Lispy, etc. (This is how > the structure of the getaddrinfo_a library already works.) > Just for the record, getaddrinfo_a creates at least one detached worker thread to synchronously call getaddrinfo. If all threads are busy, it will spawn new threads. Idle workers will die eventually after some period of inactivity. So far so good. >Alain Schneble writes: > >But still, I wonder why there is no call to `gai_cancel' at all. What I meant with this is that, when working with external resources, the caller should explicitly account for the "unusual" (e.g. shutdown) cases as well, explicitly, IMHO. Given the case where any number of async DNS requests are still pending and the (OS) process is to be terminated, it should explicitly cancel all pending requests before its last heartbeat. For me, this sounds like best practice. I understand that it works properly without it in this async-DNS-feature case. But still -- maybe due to my zero knowledge about glibc -- I see the DNS resolve library as a black box. It could well have started let's say a new OS process which does the resolve and which would survive our "initiator" OS process if the requests are not explicitly cancelled before termination. One could argue that this would then be a bug, but maybe not. I'm happy to learn that such things won't ever happen in glibc by convention. Furthermore, in your proposal, processes with pending DNS requests are maintained in a separate list `dns_processes'. If a LISP process gets deleted by a call to `delete-process', and DNS requests are still pending for it, it might be that `connect_network_socket' will be called even though the process has been deleted. Shouldn't `deactivate_process' cancel any pending requests for that process? Or do we just forget about this probably "theoretical" case? Alain