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 11:13:25 +0100 Message-ID: <86y4b0n5q2.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> <8637t8opla.fsf@realize.ch> <871t8skg6c.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454580854 26825 80.91.229.3 (4 Feb 2016 10:14:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 10:14:14 +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 11:14:14 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 1aRGvU-0002wz-Fq for ged-emacs-devel@m.gmane.org; Thu, 04 Feb 2016 11:14:12 +0100 Original-Received: from localhost ([::1]:40654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRGvO-0004VU-ES for ged-emacs-devel@m.gmane.org; Thu, 04 Feb 2016 05:14:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRGvH-0004UH-Hq for emacs-devel@gnu.org; Thu, 04 Feb 2016 05:14:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRGvD-0004yr-DP for emacs-devel@gnu.org; Thu, 04 Feb 2016 05:13:59 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3429) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aRGv3-0004xM-Bt; Thu, 04 Feb 2016 05:13:45 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Thu, 4 Feb 2016 11:13:41 +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 11:13:27 +0100 In-Reply-To: <871t8skg6c.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 04 Feb 2016 19:55:55 +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:199290 Archived-At: Lars Ingebrigtsen writes: > It sounds like strange practice to me. >"? The OS will clean up > everything, no matter whether we're using threads or not. If not, the > OS would be pretty fragile. Agreed with the last statement. But in the general case, it could be that the clean up the OS does will result in an application inconsistent (external) state whereas an explicit cleanup won't as it may include more processing/clean up. But as it apparently does not apply to this case, I'll just stop to elaborate on this and start to learn more about the Emacs environment instead. And I'll try to no longer waste your time with this topic. I already exhausted it too much with foolish questions, I think... :) >> 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. > > That sounds like a bug. I'll get fixin'. Thanks! In this regard, I was wondering if it is really worth to maintain a separate `dns_processes' list. Why not just loop over all processes and try to get the requests for those where `p->dns_requests' is not NULL? Would that be too costly? Thanks again Alain