all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 22493@debbugs.gnu.org
Subject: bug#22493: 25.1.50; open-gnutls-stream doesn't respect :nowait, so the connections are synchronous
Date: Sat, 30 Jan 2016 11:21:43 +0200	[thread overview]
Message-ID: <83r3gzwhg8.fsf@gnu.org> (raw)
In-Reply-To: <878u37zndq.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat,  30 Jan 2016 05:45:21 +0100)

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 30 Jan 2016 05:45:21 +0100
> 
> First of all, gnutls-open-stream should call open-network-stream with
> :nowait, and put a sentinel on the stream to see when it's opened, and
> then it should call gnutls-negotiate from the sentinel.
> 
> 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?
That'd just add confusion (a.k.a. "bugs waiting to happen") on the C
level.  Can't we use a GnuTLS-specific sentinel instead?

> The other problem is that reading/writing from these things will just
> send plain text if the gnutls stuff hasn't been initialised:
> 
> #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?

> If it's p->gnutls_p, then it should never write to the process, no
> matter what the state is.  Rather is should just skip writing until
> p->gnutls_state gets set (which happens during gnutls_boot).
> 
> Or is there something subtle here I'm missing?  When would we ever want
> to write plain text to something that's p->gnutls_p?

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?

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?

Thanks.





  reply	other threads:[~2016-01-30  9:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-30  4:00 bug#22493: 25.1.50; open-gnutls-stream doesn't respect :nowait, so the connections are synchronous Lars Ingebrigtsen
2016-01-30  4:45 ` Lars Ingebrigtsen
2016-01-30  9:21   ` Eli Zaretskii [this message]
2016-01-30 22:55     ` Lars Ingebrigtsen
2016-01-31  0:40       ` Lars Ingebrigtsen
2016-01-31  1:10         ` Lars Ingebrigtsen
2016-01-31 16:00           ` Eli Zaretskii
2016-01-31 15:59         ` Eli Zaretskii
2016-01-31 23:17           ` Lars Ingebrigtsen
2016-02-01  2:41             ` Lars Ingebrigtsen
2016-02-01  3:41             ` Eli Zaretskii
2016-02-01  4:01               ` Lars Ingebrigtsen
2016-02-01 18:50                 ` Eli Zaretskii
2016-02-02  1:43                   ` Lars Ingebrigtsen
2016-02-02 16:10                     ` Eli Zaretskii
2016-02-03  1:10                       ` Lars Ingebrigtsen
2016-02-03  1:58                         ` Lars Ingebrigtsen
2016-02-03 15:52                           ` Eli Zaretskii
2016-02-04  2:47                             ` Lars Ingebrigtsen
2016-02-04 16:39                               ` Eli Zaretskii
2016-02-05  2:36                                 ` Lars Ingebrigtsen
2016-02-05  7:24                                   ` Eli Zaretskii
2016-02-05  7:34                                     ` Lars Ingebrigtsen
2016-02-05  9:18                                       ` Eli Zaretskii
2016-02-06  3:03                                         ` Lars Ingebrigtsen
2016-02-06  7:51                                           ` Eli Zaretskii
2016-02-06  7:57                                             ` Lars Ingebrigtsen
2016-02-03 15:51                         ` Eli Zaretskii
2016-02-04  2:59                           ` Lars Ingebrigtsen
2016-01-31 15:57       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r3gzwhg8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=22493@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.