From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22493: 25.1.50; open-gnutls-stream doesn't respect :nowait, so the connections are synchronous Date: Wed, 03 Feb 2016 17:52:54 +0200 Message-ID: <83fux9yend.fsf@gnu.org> References: <87mvrnzpge.fsf@gnus.org> <878u37zndq.fsf@gnus.org> <83r3gzwhg8.fsf@gnu.org> <87fuxebrsy.fsf@gnus.org> <878u36fung.fsf@gnus.org> <8360y93fka.fsf@gnu.org> <87wpqpwd8p.fsf@gnus.org> <83d1sh14is.fsf@gnu.org> <87egcx13kc.fsf@gnus.org> <83bn801d06.fsf@gnu.org> <87bn7znazd.fsf@gnus.org> <83lh73ytxo.fsf@gnu.org> <87a8nizjia.fsf@gnus.org> <8760y6zha1.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454514874 29288 80.91.229.3 (3 Feb 2016 15:54:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 15:54:34 +0000 (UTC) Cc: 22493@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 03 16:54:22 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aQzl5-0002AD-D9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 16:54:19 +0100 Original-Received: from localhost ([::1]:35785 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzl4-0002jt-Ir for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 10:54:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzkt-0002Z0-W2 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:54:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQzko-0004pq-O4 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:54:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzko-0004pm-KQ for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aQzko-00037O-Fr for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Feb 2016 15:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22493 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22493-submit@debbugs.gnu.org id=B22493.145451480311936 (code B ref 22493); Wed, 03 Feb 2016 15:54:02 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 3 Feb 2016 15:53:23 +0000 Original-Received: from localhost ([127.0.0.1]:58253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQzkA-00036R-Oj for submit@debbugs.gnu.org; Wed, 03 Feb 2016 10:53:23 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45448) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQzk5-00036B-Hz for 22493@debbugs.gnu.org; Wed, 03 Feb 2016 10:53:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQzjz-0004eX-JW for 22493@debbugs.gnu.org; Wed, 03 Feb 2016 10:53:12 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzjz-0004eT-Gd; Wed, 03 Feb 2016 10:53:11 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3080 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aQzjy-0006em-SM; Wed, 03 Feb 2016 10:53:11 -0500 In-reply-to: <8760y6zha1.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 03 Feb 2016 12:58:30 +1100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112341 Archived-At: > From: Lars Ingebrigtsen > Cc: 22493@debbugs.gnu.org > Date: Wed, 03 Feb 2016 12:58:30 +1100 > > I think you're right again. I thought I had tested this, but I hadn't: > > (progn > (setq proc (make-network-process :name "foo" > :buffer (get-buffer-create "*foo*") > :host "gmane.org" > :service "http" > :nowait t)) > (process-send-string proc "GET / HTTP/1.0\n\n")) > > With async DNS, this will fail, because the process-send-string happens > before the connection had completed. (And this isn't a TLS socket.) So > I think that (like I said on the emacs-devel threads) we may have to > change the :nowait stuff to allow a more fine-grained control. If you make process-send-string wait until DNS completes, the problem will disappear. Then, if code such as above wants better async behavior, its maintainer will have to restructure the code, for example like this: > So the rule would be if you want a fully async connection, you have to > say ":nowait 'dns" or something, and then put a sentinel on the process > to not do anything until it changes status to "connected". (This is > what url.el does already, which is why I didn't see this before...) But if the code is not changed, it should still "just work", albeit not as fast as it could. > With a TLS socket: > > make-network-process gives us a process in "open", and then when it > changes to "connected" (after connecting the socket) we can't start > talking. We have to wait until the TLS has been negotiated. So perhaps > it should only move to the "connected" state after the negotiation has > finished? Or introduce more states? Like with process-send-string, we could make gnutls-boot wait until DNS resolution completes (and error out if DNS fails). As for making gnutls-boot run in the background, I'm still not convinced it buys us enough advantages (or any advantages) to justify the changes. Let's continue discussing that, OK? Running gnutls-boot from a separate thread on the C level is also possible, but AFAIU that requires a total rewrite of the current C implementation, as it does a lot of stuff that cannot be done from a non-main thread. Either way, if we decide that making gnutls-boot run in the background is a Good Thing, then I feel that doing so requires code restructuring that must involve application-level considerations. So these changes probably shouldn't be done on the level of open-gnutls-stream. Instead, we should provide the building blocks for applications that want this, and let them restructure their code as they see fit. Trying to do that transparently controlled by a single argument is not going to work well, I think.