From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: contovob@tcd.ie, 24201@debbugs.gnu.org, eggert@cs.ucla.edu
Subject: bug#24201: 25.1.50; TLS connections sometimes hang
Date: Sat, 06 Jul 2019 14:16:01 +0200 [thread overview]
Message-ID: <m3lfxbgxz2.fsf@gnus.org> (raw)
In-Reply-To: <83muhs9x5i.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jul 2019 21:03:21 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> Yes, normally when this code is triggered by the timer, there's other
>> networking happening more or less at the same time.
>
> So maybe another process steals the response?
That's possible...
>> That's not what the doc string says, I think?
>>
>> --
>> Optional second argument SECONDS and third argument MILLISEC
>> specify a timeout; return after that much time even if there is
>> no subprocess output.
>> --
>>
>> "even if"...
>
> But if output is available, accept-process-output will return
> immediately, so "even if" really means "if".
Yeah, that's true. But it should, in an case, not keep spinning (much)
longer than the timeout, whether there's any output or not...
>> Without the JUST-THIS-ONE parameter, accept-process-output seems to loop
>> until the peer closes the connection. And then control is returned to
>> Lisp world and the data is in the buffer.
>
> Since you are saying that the remote does respond, this would mean the
> responses get lost somehow, or are consumed by other filter functions.
> The question is how can that happen?
What I'm seeing happening if I instrument the loop in the Lisp part with:
(while (and (memq (process-status stream) '(open run))
(not (re-search-forward end-of-command nil t)))
(push (buffer-string) my-output-list)
(accept-process-output stream 0.05)
(goto-char start))
is that when Emacs hangs, and I `C-g' after half a minute, I will get 1
"" (empty string) entry in that list, so the timeout isn't heeded.
But -- in the buffer where this is happening, the data this is waiting
for is present, so Emacs got the response and put it into the buffer --
but then just kept on spinning in wait_reading_process_output,
apparently.
I'll add some instrumentation to that function now and try to figure out
why it's not heeding the timeout. It's so annoying that I haven't been
able to make a simple test case to reproduce the error, though, because
the hang only happens once every few hours...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2019-07-06 12:16 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 13:20 bug#24201: 25.1.50; TLS connections sometimes hang Lars Ingebrigtsen
2016-08-15 2:35 ` Paul Eggert
2016-10-10 10:36 ` Eli Zaretskii
2016-10-10 10:54 ` Lars Ingebrigtsen
2016-10-10 11:23 ` Eli Zaretskii
2017-09-02 12:40 ` Eli Zaretskii
2017-09-02 13:04 ` Lars Ingebrigtsen
2017-09-02 14:21 ` Eli Zaretskii
2018-02-18 17:57 ` Lars Ingebrigtsen
2018-02-19 16:52 ` Lars Ingebrigtsen
2018-02-19 17:56 ` Paul Eggert
2018-02-19 18:16 ` Lars Ingebrigtsen
2018-02-19 18:32 ` Eli Zaretskii
2018-02-19 19:06 ` Lars Ingebrigtsen
2018-02-19 19:57 ` Eli Zaretskii
2018-02-19 20:39 ` Lars Ingebrigtsen
2019-06-24 13:25 ` Lars Ingebrigtsen
2019-06-24 19:20 ` Eli Zaretskii
2019-06-24 20:46 ` Lars Ingebrigtsen
2019-06-25 19:15 ` Lars Ingebrigtsen
2019-06-25 21:57 ` Lars Ingebrigtsen
2019-06-26 16:32 ` Eli Zaretskii
2019-06-27 10:34 ` Lars Ingebrigtsen
2019-06-27 13:25 ` Eli Zaretskii
2019-06-27 19:28 ` Lars Ingebrigtsen
2019-06-28 6:19 ` Eli Zaretskii
2019-06-28 8:25 ` Lars Ingebrigtsen
2019-06-28 8:34 ` Eli Zaretskii
2019-06-28 9:55 ` Lars Ingebrigtsen
2019-06-28 12:26 ` Eli Zaretskii
2019-06-28 14:39 ` Basil L. Contovounesios
2019-06-28 14:50 ` Eli Zaretskii
2019-06-30 19:02 ` Lars Ingebrigtsen
2019-07-04 13:04 ` Lars Ingebrigtsen
2019-07-04 19:05 ` Eli Zaretskii
2019-07-05 12:59 ` Lars Ingebrigtsen
2019-07-05 18:03 ` Eli Zaretskii
2019-07-06 12:16 ` Lars Ingebrigtsen [this message]
2019-07-07 18:13 ` Lars Ingebrigtsen
2019-07-07 18:18 ` Eli Zaretskii
2019-07-08 16:38 ` Lars Ingebrigtsen
2020-08-03 6:00 ` Lars Ingebrigtsen
2019-07-05 8:21 ` Eli Zaretskii
2019-07-05 13:13 ` Lars Ingebrigtsen
2019-06-26 16:29 ` Eli Zaretskii
2018-02-19 18:37 ` Andreas Schwab
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=m3lfxbgxz2.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=24201@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.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.