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: Fri, 12 Feb 2016 11:12:15 +0100 Message-ID: <86egci6xvk.fsf@realize.ch> References: <83y4b0wi7m.fsf@gnu.org> <87si17evk6.fsf@gnus.org> <83twlnvcz2.fsf@gnu.org> <87vb63obm3.fsf@gnus.org> <87r3gqmg6g.fsf@gnus.org> <83egcqtfnm.fsf@gnu.org> <86mvrdmk8p.fsf@realize.ch> <877fihjo4m.fsf@gnus.org> <86io20n3xn.fsf@realize.ch> <8760y055l1.fsf@gnus.org> <8660xzmyyr.fsf@realize.ch> <87pow7ocyw.fsf@gnus.org> <861t8nmxlj.fsf@realize.ch> <87y4auiurw.fsf@gnus.org> <86k2me8dee.fsf@realize.ch> <83a8n9ddk5.fsf@gnu.org> <864mdh8vj5.fsf@realize.ch> <87pow579kt.fsf@gnus.org> <86ziv87st0.fsf@realize.ch> <87vb5u4qtq.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1455271995 5984 80.91.229.3 (12 Feb 2016 10:13:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Feb 2016 10:13:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 12 11:13:11 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 1aUAir-0001cw-VO for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2016 11:13:10 +0100 Original-Received: from localhost ([::1]:59382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUAiq-0004B5-Nt for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2016 05:13:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUAij-0004AQ-E8 for emacs-devel@gnu.org; Fri, 12 Feb 2016 05:13:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUAif-00044C-12 for emacs-devel@gnu.org; Fri, 12 Feb 2016 05:13:01 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:1502) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aUAie-00042y-M2 for emacs-devel@gnu.org; Fri, 12 Feb 2016 05:12:56 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Fri, 12 Feb 2016 11:12:43 +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; Fri, 12 Feb 2016 11:12:17 +0100 In-Reply-To: <87vb5u4qtq.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 12 Feb 2016 13:15:13 +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:199803 Archived-At: Lars Ingebrigtsen writes: > By the way, the "make all process functions wait until the connection > has been set up" will make functions that currently are non-blocking > become blocking. For instance, erc creates a :nowait t connection, and > then calls set-process-coding-system immediately. And then it sets up a > sentinel that will complete login once the connection changes to 'open. > > Unless I'm misreading the code, making functions like that blocking will > make stuff that's currently quite asynchronous become more asynchronous. You mean less asynchronous. Or more synchronous. :) You are right, I also think it would if the function waits for full connection set up. > We could fix that, of course -- there's really no reason for that > function to be checking infd/outfd, I think? But this is something that > has to be done on a function by function basis unless we want > regressions in how asynchronous :nowait t connections are. Currently, IINW, `set-process-coding-system' calls `setup_process_coding_systems' which basically requires infd/outfd to /complete/ its "task". Otherwise it just returns. Later in the flow, `connect_network_socket' will be called and it invokes `set_network_socket_coding_system' near the end which in turn invokes `setup_process_coding_systems'. So it looks like it will complete the "task" anyway. But wait, AFAICS, in this case, the encodings that were specified in the initial call to `set-process-coding-system' will be overwritten, right? Hence, I don't think it will work properly if we just do not check for infd/outfd... Another approach could be to just wait until the socket has been initialized (instead of connected), i.e. wait on a more fine grained (internal) process state than just wait for 'run. Not sure, but async TLS handling could benefit from such a state as well. Of course, we kind of have it already implicitly, e.g. with p->dns_requests for example. As you said, after all, we'll have to look at each case in detail.