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: Sun, 31 Jan 2016 17:57:21 +0200 Message-ID: <837fip3foe.fsf@gnu.org> References: <87mvrnzpge.fsf@gnus.org> <878u37zndq.fsf@gnus.org> <83r3gzwhg8.fsf@gnu.org> <87fuxebrsy.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454255964 9000 80.91.229.3 (31 Jan 2016 15:59:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Jan 2016 15:59:24 +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 Sun Jan 31 16:59:13 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 1aPuPA-0004WF-KS for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 16:59:12 +0100 Original-Received: from localhost ([::1]:42140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPuP9-00080f-Ul for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 10:59:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPuP4-00080D-6w for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 10:59:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPuP0-0004yI-6o for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 10:59:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPuP0-0004yE-2b for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 10:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPuOz-0004IS-TM for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 10:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jan 2016 15:59: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.145425588616450 (code B ref 22493); Sun, 31 Jan 2016 15:59:01 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 31 Jan 2016 15:58:06 +0000 Original-Received: from localhost ([127.0.0.1]:43278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPuO2-0004HC-VT for submit@debbugs.gnu.org; Sun, 31 Jan 2016 10:58:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34363) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPuNx-0004Gg-RL for 22493@debbugs.gnu.org; Sun, 31 Jan 2016 10:58:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPuNo-0004i7-Bx for 22493@debbugs.gnu.org; Sun, 31 Jan 2016 10:57:52 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPuNo-0004hy-8a; Sun, 31 Jan 2016 10:57:48 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3574 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aPuNn-0005qw-GL; Sun, 31 Jan 2016 10:57:47 -0500 In-reply-to: <87fuxebrsy.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Jan 2016 23:55:57 +0100) 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:112134 Archived-At: > From: Lars Ingebrigtsen > Cc: 22493@debbugs.gnu.org > Date: Sat, 30 Jan 2016 23:55:57 +0100 > > Eli Zaretskii writes: > > >> The problem is, though, that the process isn't marked as a gnutls > >> process until gnutls_boot is called, so this needs to happen much > >> earlier. Possibly by adding another keyword to make-network-process > >> that just sets > >> > >> XPROCESS (proc)->gnutls_p = 1; > > > > Why do you need to mark a process gnutls_p, when it definitely still > > isn't, not until the GnuTLS negotiation is successfully completed? > > It is a socket that will only be used for TLS. And the current way > we're creating TLS streams is by calling `open-gnutls-stream', which > (simplified) just calls `make-network-stream' and then `gnutls-boot' in > rapid succession. So any stream you get out of `open-gnutls-stream' > will look just the same -- it'll have gnutls_p set. > > It'll just happen slightly earlier. There's a certain semantics to this flag being set, and overloading it doesn't sound like a good idea to me. But this is a minor issue -- the larger one is below. > >> #ifdef HAVE_GNUTLS > >> if (p->gnutls_p && p->gnutls_state) > >> written = emacs_gnutls_write (p, cur_buf, cur_len); > >> else > >> #endif > >> written = emacs_write_sig (outfd, cur_buf, cur_len); > >> > >> I think that looks rather nonsensical. > > > > Does this happen today? If so, in what scenario? > > It does not happen today, but it will happen if we open the TLS stream > :nowait. So not doing that will avoid this problem. Good. > > If you want GnuTLS negotiation to happen from the sentinel, you need > > some machinery to block such process objects from communicating. > > I'm not sure silently skipping I/O is TRT for that: won't Lisp > > programs that happen to start communicating too early become confused > > about what's going on? > > The "GET /" will block, sort of, as it would on any socket that's backed > up. That depends on what the (as yet unwritten) code will do when it gets to the above fragment and discovers that GnuTLS did not yet finish handshaking. You didn't really describe what you intend to do. Your options are (a) silently do nothing, or (b) fail the write. Either way sounds problematic to me. > > More generally, what advantages do we expect to gain by making these > > changes? Let DNS resolution proceed in the background, only to have > > to wait for GnuTLS negotiations anyway, before we can start using the > > stream? Or are there more significant advantages? > > It makes the entire connection, both the DNS resolution and the TLS > negotiation, asynchronous. So Emacs doesn't hang while eww is > connecting to https://google.com. I guess I'm missing something important here, because I don't understand how can this work. Async DNS works because getaddrinfo_a starts threads under the hood to perform the resolution, while the main (a.k.a. "Lisp") thread is free to do other things, until a call to 'pselect' tells it the DNS resolution is complete. By contrast, the GnuTLS negotiation, whether it runs from a sentinel or from inside open-network-stream, runs in the main thread, so Emacs must wait for it to finish before it can do anything else. Running it from a sentinel doesn't magically make it asynchronous, since sentinels run in the main thread, and the main thread is busy as long as the sentinel runs. Maybe you thought about running gnutls-boot from a separate thread, but I see no easy way of doing that, without some very thorough rewrite, since current code access Lisp data structures an (at least optionally) displays logging messages in the echo area. So how will this work asynchronously? What am I missing?