From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Mon, 08 Feb 2016 13:03:44 +1100 Message-ID: <871t8o556n.fsf@gnus.org> 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> <86mvrdmk8p.fsf@realize.ch> <83mvrcsefa.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454897071 18888 80.91.229.3 (8 Feb 2016 02:04:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 02:04:31 +0000 (UTC) Cc: Alain Schneble , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 08 03:04:21 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 1aSbBb-0004mL-P6 for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 03:04:20 +0100 Original-Received: from localhost ([::1]:40119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSbBa-0000lZ-Eo for ged-emacs-devel@m.gmane.org; Sun, 07 Feb 2016 21:04:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSbBW-0000l9-QO for emacs-devel@gnu.org; Sun, 07 Feb 2016 21:04:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSbBT-0004Yi-G7 for emacs-devel@gnu.org; Sun, 07 Feb 2016 21:04:14 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:57809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSbBT-0004YZ-9F; Sun, 07 Feb 2016 21:04:11 -0500 Original-Received: from cpe-60-225-211-161.nsw.bigpond.net.au ([60.225.211.161] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aSbB7-0001Fb-5u; Mon, 08 Feb 2016 03:03:49 +0100 In-Reply-To: <83mvrcsefa.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Feb 2016 17:55:37 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux) X-MailScanner-ID: 1aSbB7-0001Fb-5u MailScanner-NULL-Check: 1455501829.96597@BjSbuSSSMYcDX2GaTVlPEg X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.224.195 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:199476 Archived-At: Eli Zaretskii writes: > Please consider the plight of a programmer who needs to implement such > a connection. It would be much more complex and hard to get right > than what we have today. E.g., look at smtpmail.el: it opens the > network stream, sets up the process filter and encoding, and > immediately proceeds to sending the HELO command to the server. > Imagine how much more complex this simple job would be if it needed to > jump through hoops as you described above. Ideally, when you're sending mail with smtpmail.el, it would all happen without Emacs being blocked, right? So that the user can go on reading the next email. But that can't be done without doing major changes to smtpmail.el. Way errors are propagated back to the callers would have to change, for instance. I guess what I'm saying is this: If you're fine blocking Emacs, then you don't use :nowait 'immediate. Then everything happens one step at a time (DNS, connect, TLS, EHLO, QUIT). If you wish to make things happen "in the background", then you will have to change your application in major ways. Making one of those things the rule "you have to wait until the process changes state to "connected" is an insignificant part of that rewrite. > They all should call a single function that waits calling gai_error > until the connection completes, and signals an error if it completes > with a failure indication. Then you're back to making a blocking connection, which is something that somebody who's said :nowait 'immediate would not want. So I don't really see the point here. It's better to just have those functions signal an error, I think, which is what they currently do... > Yes, I understand. But I don't think this is a proper way to be > backward compatible. With my suggestion, code remains backward > compatible even if it uses :nowait. This is better, IMO, because it > leaves more applications backward compatible. For example, imagine > that :nowait comes from some higher level, so the level that arranges > the connection has no idea whether it needs to do the simple thing or > the complex one. What Lars suggested means that every application > that doesn't pass literal parameters to make-network-process will now > have to analyze the parameters passed by the caller, to see if :nowait > is there and what is its value. I don't expect package maintainers to > love this. Hm... I don't understand. An application that wants 'immediate will just say ":nowait 'immediate". The only thing that examines the :nowait parameter (to distinguish 'immediate, nil and non-nil) is make-network-process. Unless I'm missing something. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no