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, 7 Feb 2016 01:34:14 +0100 Message-ID: <86mvrdmk8p.fsf@realize.ch> References: <87si1gx6wz.fsf@gnus.org> <86y4b5zvzt.fsf@gmail.com> <8760y9kwrk.fsf@gnus.org> <8760y7nag7.fsf@gnus.org> <83oabzzsjq.fsf@gnu.org> <87fuxazkfe.fsf@gnus.org> <83io25yeqk.fsf@gnu.org> <87h9hpnreg.fsf@gnus.org> <83y4b0wi7m.fsf@gnu.org> <87si17evk6.fsf@gnus.org> <83twlnvcz2.fsf@gnu.org> <87vb63obm3.fsf@gnus.org> <87r3gqmg6g.fsf@gnus.org> <83egcqtfnm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454805311 11432 80.91.229.3 (7 Feb 2016 00:35:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Feb 2016 00:35:11 +0000 (UTC) Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 07 01:35:07 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 1aSDJh-0008VY-7h for ged-emacs-devel@m.gmane.org; Sun, 07 Feb 2016 01:35:05 +0100 Original-Received: from localhost ([::1]:57886 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSDJg-0003S5-B7 for ged-emacs-devel@m.gmane.org; Sat, 06 Feb 2016 19:35:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSDJQ-0003Rt-41 for emacs-devel@gnu.org; Sat, 06 Feb 2016 19:34:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSDJM-0008Pg-8s for emacs-devel@gnu.org; Sat, 06 Feb 2016 19:34:48 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:1191) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aSDJH-0008Ma-DC; Sat, 06 Feb 2016 19:34:39 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Sun, 7 Feb 2016 01:34:30 +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, 7 Feb 2016 01:34:11 +0100 In-Reply-To: <83egcqtfnm.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Feb 2016 10:19:09 +0200") 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:199429 Archived-At: Eli Zaretskii writes: >> From: Lars Ingebrigtsen >> Date: Sat, 06 Feb 2016 18:49:43 +1100 >> >> I kinda think we've gotten as far as we're going to get in this >> discussion, and that it's time to merge. > > I'm sorry, but I disagree. I think the APIs that expect a fully > functional process object should wait for the DNS resolution to > complete, before they do anything. FWIW, the process-send-* functions do not wait for an async connection to complete either, even without async-DNS-feature turned on. They throw an error if called before the async connection completed, IIUC. And the documentation does not mention anything about this behavior. It seems to me like it is a matter of definition to say which functions should work properly also before an async connection is established and which not. If backward compatibility were not an issue, we could also adopt a more restrictive approach where errors would be thrown in many of the functions accepting a (async socket) Lisp process and requiring a valid infd/outfd before async connection completion. Documentation of `make-network-process' could say something like "if :nowait is t, process returned shall not be used in any call before async connection has completed. Consider performing any required process configuration withing the SENTINEL". Oops, just realized that this is what Lars more or less put in the doc string for the 'dns case... Just as an overview, here is an extract of functions relying on a valid infd/outfd and hence would be candidates that could either throw errors or, as you suggested, synchronously wait for the DNS resolution to complete. There are quite a few though: `process-contact', `set-process-filter', `set-process-filter-multibyte', `set-process-window-size', `set-network-process-option', `set-process-coding-system', `process-filter-multibyte-p', `process-datagram-address', `set-process-datagram-address', `process-send-region', `process-send-string', `process-send-eof' >> There should be no impact on any existing use. It should be 100% >> backward compatible. > > But it isn't, as was demonstrated by ERC. And it cannot be 100% > backward compatible, unless the above-mentioned waiting is added to > the affected APIs. I think what Lars meant was that with :nowait to t, client code should be 100% backward compatible, as async connection establishment is still handled the same way internally. Only when :nowait is 'dns, the new async DNS resolution is activated. And only in this case, we might run into /new/ issues with calls to functions accepting a Lisp process, such as the issue revealed by ERC before Lars introduced 'dns. On one hand, I see the practical approach with the 'dns async mode to circumvent these compatibility issues. On the other hand, I don't think it's a good choice from a interface/usage point of view. I think it is not clear for a user why she has to care about whether both async DNS and async socket connection or only the latter shall be used and why the process behavior is different. This distinction only makes sense with the knowledge of how it's implemented internally, I think. I guess changing the semantics of :nowait t, to say that clients shall not use the returned process before connection is established, is out of discussion, right? Or do you think that this would even be a ridiculous restriction (even without the backward compatibility issue)?