bug#24201: 25.1.50; TLS connections sometimes hang

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  24201@debbugs.gnu.org,  eggert@cs.ucla.edu
> Date: Fri, 05 Jul 2019 14:59:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> -    (accept-process-output stream 0.05)
> >> +    (accept-process-output stream 0.05 nil t)
> >>      (goto-char start))
> >>    ;; Return the data we got back, or nil if the process died.
> >>    (unless (= start (point))
> >
> > Does this mean you have other process objects active at that time?
> 
> 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?

> >> It's the JUST-THIS-ONE parameter: If that's non-nil, then
> >> accept-process-output returns after the timeout...  and we get the data.
> >
> > I don't understand: accept-process-output is supposed to hit the
> > timeout only when there's no data. 
> 
> 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".

> 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?