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:51:53 +0200 Message-ID: <83h9hpyep2.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454515292 4784 80.91.229.3 (3 Feb 2016 16:01:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 16:01:32 +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 17:01:21 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 1aQzrs-0002qN-44 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 17:01:20 +0100 Original-Received: from localhost ([::1]:35894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzrr-0002pO-MV for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 11:01:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzjv-00013h-Ot for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:53:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQzjq-0004c4-Ol for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:53:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzjq-0004bx-Ea for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aQzjq-00035j-7F for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 10:53: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:53: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.145451474711843 (code B ref 22493); Wed, 03 Feb 2016 15:53:02 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 3 Feb 2016 15:52:27 +0000 Original-Received: from localhost ([127.0.0.1]:58249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQzjH-00034w-Dg for submit@debbugs.gnu.org; Wed, 03 Feb 2016 10:52:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44819) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQzjE-00034j-LD for 22493@debbugs.gnu.org; Wed, 03 Feb 2016 10:52:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQzj2-00042f-1H for 22493@debbugs.gnu.org; Wed, 03 Feb 2016 10:52:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQzj1-00042a-Hh; Wed, 03 Feb 2016 10:52:11 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3079 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aQzj0-0006Rx-N8; Wed, 03 Feb 2016 10:52:11 -0500 In-reply-to: <87a8nizjia.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 03 Feb 2016 12:10:21 +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:112342 Archived-At: > From: Lars Ingebrigtsen > Cc: 22493@debbugs.gnu.org > Date: Wed, 03 Feb 2016 12:10:21 +1100 > > >> Sure. But the wait is much shorter. > > > > If it really is, then I must be missing something, because I don't see > > how it could. Can you show some timings, comparing the "old" and the > > "new" methods for making a GnuTLS connection? > > You don't see how taking the DNS resolution out of the "stop everything > Emacs is doing" bit makes Emacs stop everything it's doing for a shorter > while? Of course I do. But this thread is not about async DNS, it's about async GnuTLS initialization. I'm asking how attempting to do that in the background, _after_ DNS resolution ended, makes the wait shorter. IOW, I have nothing against using getaddrinfo_a where it's available (or emulate it where it isn't). But I don't see any visible advantages to backgrounding the GnuTLS negotiation, because the way you did it, it runs in the main thread, and so doesn't save us any waiting time, AFAIU. All it does is tremendously increase complexity of starting a TLS connection. > > And if somehow it indeed is shorter, the same effect can be achieved > > by running the GnuTLS negotiation from an idle timer, something that > > would most probably avoid most or all of the complexities on the C > > level. Have you considered this alternative? > > Sure, but we were talking about the DNS resolution... No, we weren't. This is about the parts of open-gnutls-stream, which runs _after_ the DNS resolution. The changes which I reviewed and commented on, and which bother me, are those in gnutls.el and elsewhere that are related to the initial GnuTLS negotiation. > > This will have to be optional, since Emacs might not become idle for a > > prolonged time. IOW, only certain applications will want to benefit > > from such a background handshake, some will need to wait for its > > completion. So if you make this be a background thing by default, you > > might break existing users that don't expect the negotiation to return > > before it's completed or failed. > > Sure. The optional part here is that the user says :nowait when they > don't want to wait, so I'm not sure I'm getting your objection here, > either. An application may wish to make DNS resolution asynchronous, but might not rely on Emacs becoming idle for GnuTLS initialization. IOW, we need a separate option for that. > If the user has requested a TLS socket, then it's nonsensical to try > sending data on it before it's completed the negotiation. So make the sending function wait for the end of the negotiation. > > One final comment: I think this change will need addition of tests to > > the test suite, to exercise the affected APIs, so we could make sure > > we don't introduce any bugs in the existing functionalities. > > Unfortunately, there are virtually no network tests in the suite. At > least I couldn't find any. I know. We need to add them. Such a radical change in the core infrastructure used all over the place cannot be trusted without some minimal testing of the popular paradigms of its usage. E.g., does synchronous URL retrieval still work? what about asynchronous one? what about SMTP with TLS? etc. etc. There's a potential here to break a lot of functionality out there.