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: Thu, 04 Feb 2016 18:39:27 +0200 Message-ID: <83wpqkwhts.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> <83fux9yend.fsf@gnu.org> <87a8nhnqdy.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454604030 7995 80.91.229.3 (4 Feb 2016 16:40:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 16:40:30 +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 Thu Feb 04 17:40:18 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 1aRMx2-0002UX-Ty for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 17:40:13 +0100 Original-Received: from localhost ([::1]:42821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRMx1-0003YD-AO for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 11:40:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRMww-0003Ve-88 for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 11:40:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRMws-0002Bl-8W for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 11:40:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRMws-0002Be-5e for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 11:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRMws-0001we-0d for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 11:40: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: Thu, 04 Feb 2016 16:40:01 +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.14546039997463 (code B ref 22493); Thu, 04 Feb 2016 16:40:01 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 4 Feb 2016 16:39:59 +0000 Original-Received: from localhost ([127.0.0.1]:60488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRMwp-0001wI-0r for submit@debbugs.gnu.org; Thu, 04 Feb 2016 11:39:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48701) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRMwn-0001w5-7R for 22493@debbugs.gnu.org; Thu, 04 Feb 2016 11:39:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRMwe-00029O-5y for 22493@debbugs.gnu.org; Thu, 04 Feb 2016 11:39:52 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRMwe-00029D-28; Thu, 04 Feb 2016 11:39:48 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4307 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aRMwX-000304-I5; Thu, 04 Feb 2016 11:39:42 -0500 In-reply-to: <87a8nhnqdy.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 04 Feb 2016 13:47:05 +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:112412 Archived-At: > From: Lars Ingebrigtsen > Cc: 22493@debbugs.gnu.org > Date: Thu, 04 Feb 2016 13:47:05 +1100 > > Eli Zaretskii writes: > > >> 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. > > Yes. That was basically what the > > #ifdef HAVE_GNUTLS > /* The TLS connection hasn't been set up yet, so we can't write > anything on the socket. */ > if (!NILP (p->gnutls_boot_parameters)) > return; > #endif > > in send_process achieves (in the TLS case). No, I meant to actually wait: loop checking the async DNS status until that indicates the DNS resolution is complete, or fails. > if (!NILP (p->gnutls_boot_parameters) || p->outfd == 0) > return; > > then that will have the same effect on non-TLS sockets. But as noted in > the previous email, set-process-coding-system would also have to be > changed to remove these outfd guards... Every API that expects a fully-capable process object should have such a wait for DNS added to it. And if we make GnuTLS negotiation run in the background, they should also wait for that to complete. An application that doesn't want to wait will have to "do other things" without calling these functions, and from time to time check whether the background processing is complete (which might require an additional API). > OK: eww has displayed a web page, and now wants to fetch an image over > https. Our goal is to have Emacs stop as little as possible while this > is happening in the background, so that the user can scroll around or do > whatever the user wants to do while eww is working on getting the image. > > So eww issues a url-retrieve command in the background, which ends up > calling make-network-process :nowait t. This returns immediately, with > no user-noticeable hangs. getaddrinfo_a has been issued, and after a > while a response is received and is noticed by the idle loop. > > Emacs then calls connect_network_process. This basically is a wrapper > around the connect(2), and it's pretty async on a non-blocking socket, > so this should not be noticeable to the user. > > Everything up until now has happened identically for TLS and non-TLS > sockets. > > Now, for a TLS socket, we have to do the negotiating. This is currently > a blocking process, but it doesn't have to be. The GnuTLS library in > itself is non-blocking, but our interaction with it currently is. > > So we call gnutls_boot after the connection has happened. I originally > did this with a sentinel on a process, but that doesn't really work, > because the callers of make_network_process want their own sentinels on > the process. So I call gnutls_boot from the C layer instead of from a > sentinel. > > No matter how we call gnutls_boot, it will currently hang Emacs while > it's transferring all those certificates back and forth. That last sentence is exactly the point I was trying to make all along: we have to wait for this, therefore any time savings from running gnutls_boot in the background are minor or even non-existent. So I question the need for complicating the heck out of the underlying code, for no practical gain. > > 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. > > Actually, almost all of the major network usages in Emacs today require > no changes. The only one I've found is erc. url.el, Gnus, smtpmail, > imap.el, nntp.el all work without any changes with the current > implementation. Why shouldn't we assume that the problem you saw in erc is the tip of an iceberg, and the other places are happy exceptions? Who knows how many other packages are out there that are like erc? And again, I don't see the gains in doing gnutls-boot asynchronously. DNS resolution, yes, but gnutls-boot is another matter.