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: Tue, 21 Apr 2020 22:20:03 +0000 (UTC) [thread overview]
Message-ID: <864ktcfpm5.fsf@mail.3qin.us> (raw)
In-Reply-To: <86368w1tge.fsf@mail.3qin.us>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
Derek Zhou writes:
> Robert Pluim writes:
>
>> Thatʼs always possible. You'd have to stick some instrumentation in
>> things like connect_network_socket and wait_reading_process_output to
>> narrow it down.
>>
> I think what happened is gnutls's internal buffering exhausts the
> available data from the socket, so select blocks. There is an comment in
> the code said gnutls leave one byte in the socket for select, but I
> don't think it is doing this anymore. The following patch move the check
> before the select and skip the select if there is data to be read in
> gnutls. It fixed the occational stall in https.
Sorry, the previous patch was wrong. Cannot reuse the fd_set intended
for select. Corrected:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: check_pending_before_select.patch --]
[-- Type: text/x-diff, Size: 3376 bytes --]
diff --git a/src/process.c b/src/process.c
index 91d426103d..49b034b1a7 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5566,7 +5566,38 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
}
#endif
-/* Non-macOS HAVE_GLIB builds call thread_select in xgselect.c. */
+#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_set tls_available;
+ FD_ZERO (&tls_available);
+ nfds = 0;
+ 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);
+ }
+ }
+ /* don't select if we have something here */
+ if (nfds > 0) {
+ Available = tls_available;
+ goto SELECT_END;
+ }
+ }
+#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,
&Available, (check_write ? &Writeok : 0),
@@ -5582,65 +5613,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
(check_write ? &Writeok : 0),
NULL, &timeout, NULL);
#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)
- {
- 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;
- }
-#endif
}
+ SELECT_END:
xerrno = errno;
/* Make C-g and alarm signals set flags again. */
next prev parent reply other threads:[~2020-04-21 22: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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=864ktcfpm5.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 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.