From: Derek Zhou <derek@3qin.us>
To: Robert Pluim <rpluim@gmail.com>
Cc: 40665@debbugs.gnu.org
Subject: bug#40665: 28.0.50; tls hang on local ssl
Date: Thu, 23 Apr 2020 02:20:53 +0000 (UTC) [thread overview]
Message-ID: <86y2qnaqnv.fsf@mail.3qin.us> (raw)
In-Reply-To: <m2eesffqg7.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
Robert Pluim writes:
> OK, that does make sense, and might even be more correct, but itʼs a
> bigger change. You'll need more than just me to agree with it.
>
Patch reworked:
* before the select, check every interesting gnutls stream for
available data in the buffer
* if some of them hit, and either there is no wait_proc or the
wait_proc is one of the gnutls streams with new data, set the select
timeout to 0
* after the select, merge the gnutls buffer status into the select
returns
The patch is not much longer than before, still a net reduction of code
lines. I've done some light testing and haven't found any problem.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: check_pending_before_select.patch --]
[-- Type: text/x-diff, Size: 4082 bytes --]
diff --git a/src/process.c b/src/process.c
index 91d426103d..783ce098b3 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5497,6 +5497,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
}
else
{
+#ifdef HAVE_GNUTLS
+ int tls_nfds;
+ fd_set tls_available;
+#endif
/* Set the timeout for adaptive read buffering if any
process has non-zero read_output_skip and non-zero
read_output_delay, and we are not reading output for a
@@ -5566,6 +5570,36 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
}
#endif
+#ifdef HAVE_GNUTLS
+ /* GnuTLS buffers data internally. We need to check if some
+ data is available in the buffers manually before the select.
+ And if so, we need to skip the select which could block */
+ FD_ZERO (&tls_available);
+ tls_nfds = 0;
+ for (channel = 0; channel < FD_SETSIZE; ++channel)
+ if (! NILP (chan_process[channel]) && FD_ISSET(channel, &Available))
+ {
+ struct Lisp_Process *p =
+ XPROCESS (chan_process[channel]);
+ if (p && p->gnutls_p && p->gnutls_state
+ && ((emacs_gnutls_record_check_pending
+ (p->gnutls_state))
+ > 0))
+ {
+ tls_nfds++;
+ eassert (p->infd == channel);
+ FD_SET (p->infd, &tls_available);
+ }
+ }
+ /* if wait_proc is somebody else, we have to wait in select as usual.
+ Otherwisr, clobber the timeout */
+ if ((tls_nfds > 0) &&
+ (!wait_proc ||
+ (wait_proc->infd >= 0 &&
+ FD_ISSET(wait_proc->infd, &tls_available))))
+ timeout = make_timespec (0, 0);
+#endif
+
/* Non-macOS HAVE_GLIB builds call thread_select in xgselect.c. */
#if defined HAVE_GLIB && !defined HAVE_NS
nfds = xg_select (max_desc + 1,
@@ -5584,60 +5618,22 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
#endif /* !HAVE_GLIB */
#ifdef HAVE_GNUTLS
- /* GnuTLS buffers data internally. In lowat mode it leaves
- some data in the TCP buffers so that select works, but
- with custom pull/push functions we need to check if some
- data is available in the buffers manually. */
- if (nfds == 0)
+ /* merge tls_available into Available */
+ if (tls_nfds > 0)
+ {
+ if (nfds == 0 || (nfds < 0 && errno == EINTR))
{
- fd_set tls_available;
- int set = 0;
-
- FD_ZERO (&tls_available);
- if (! wait_proc)
- {
- /* We're not waiting on a specific process, so loop
- through all the channels and check for data.
- This is a workaround needed for some versions of
- the gnutls library -- 2.12.14 has been confirmed
- to need it. */
- for (channel = 0; channel < FD_SETSIZE; ++channel)
- if (! NILP (chan_process[channel]))
- {
- struct Lisp_Process *p =
- XPROCESS (chan_process[channel]);
- if (p && p->gnutls_p && p->gnutls_state
- && ((emacs_gnutls_record_check_pending
- (p->gnutls_state))
- > 0))
- {
- nfds++;
- eassert (p->infd == channel);
- FD_SET (p->infd, &tls_available);
- set++;
- }
- }
- }
- else
- {
- /* Check this specific channel. */
- if (wait_proc->gnutls_p /* Check for valid process. */
- && wait_proc->gnutls_state
- /* Do we have pending data? */
- && ((emacs_gnutls_record_check_pending
- (wait_proc->gnutls_state))
- > 0))
- {
- nfds = 1;
- eassert (0 <= wait_proc->infd);
- /* Set to Available. */
- FD_SET (wait_proc->infd, &tls_available);
- set++;
- }
- }
- if (set)
- Available = tls_available;
+ /* fast path, just copy */
+ nfds = tls_nfds;
+ Available = tls_available;
}
+ else if (nfds > 0)
+ /* slow path, merge one by one.
+ Note: nfds does not need to be accurate, just positive is enough */
+ for (channel = 0; channel < FD_SETSIZE; ++channel)
+ if (FD_ISSET(channel, &tls_available))
+ FD_SET(channel, &Available);
+ }
#endif
}
next prev parent reply other threads:[~2020-04-23 2:20 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 14:06 bug#40665: 28.0.50; tls hang on local ssl Derek Zhou
2020-04-16 16:22 ` Robert Pluim
2020-04-16 18:22 ` Derek Zhou
2020-04-16 20:47 ` Derek Zhou
2020-04-16 23:01 ` Derek Zhou
2020-04-17 18:41 ` Derek Zhou
2020-04-18 2:44 ` Derek Zhou
2020-04-19 14:34 ` Robert Pluim
2020-04-19 15:34 ` Derek Zhou
2020-04-19 16:12 ` Robert Pluim
2020-04-21 0:27 ` Derek Zhou
2020-04-21 1:41 ` Derek Zhou
2020-04-21 7:39 ` Robert Pluim
2020-04-21 13:37 ` Derek Zhou
2020-04-21 14:03 ` Robert Pluim
2020-04-21 14:45 ` Derek Zhou
2020-04-21 15:02 ` Derek Zhou
2020-04-21 15:04 ` Robert Pluim
2020-04-21 20:20 ` Derek Zhou
2020-04-21 22:20 ` Derek Zhou
2020-04-21 22:29 ` Derek Zhou
2020-04-22 8:32 ` Robert Pluim
2020-04-22 12:25 ` Derek Zhou
2020-04-22 13:12 ` Robert Pluim
2020-04-22 15:16 ` Derek Zhou
2020-04-22 16:14 ` Robert Pluim
2020-04-22 16:57 ` Derek Zhou
2020-04-23 2:20 ` Derek Zhou [this message]
2020-04-24 14:23 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-04-24 14:29 ` Robert Pluim
2020-05-07 19:08 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-31 23:22 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-02 5:34 ` Lars Ingebrigtsen
2020-08-03 5:58 ` Lars Ingebrigtsen
2020-08-03 9:44 ` Robert Pluim
2020-08-03 13:57 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-03 16:03 ` Robert Pluim
2020-08-04 8:42 ` Lars Ingebrigtsen
2020-08-04 19:28 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-04 19:45 ` Lars Ingebrigtsen
2020-08-03 13:36 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-04-17 8:35 ` Robert Pluim
2020-04-18 2:46 ` Derek Zhou
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y2qnaqnv.fsf@mail.3qin.us \
--to=derek@3qin.us \
--cc=40665@debbugs.gnu.org \
--cc=rpluim@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).