bug#24201: 25.1.50; TLS connections sometimes hang

[Lars Ingebrigtsen <larsi@gnus.org>]

I'm able to reproduce the hang more often now by artificially closing
the connection a lot and then letting it be reopened, so I'm now getting
the hangs about once an hour when using Gnus.

I changed the inflooping function like thus to record what's in it:

(defun network-stream-get-response (stream start end-of-command)
  (when end-of-command
    (with-current-buffer (process-buffer stream)
      (save-excursion
	(goto-char start)
	(while (and (memq (process-status stream) '(open run))
		    (not (re-search-forward end-of-command nil t)))
          (push (list (format-time-string "%FT%T")
                      (point)
                      (current-buffer)
                      (buffer-string))
                lars-buffers)
	  (accept-process-output stream 0.05)
	  (goto-char start))

After making this change, I've only seen the hang twice, so this is all
very preliminary, but in both hangs, it didn't really loop there.

That is, in both instances, I got something like this as the top-level
element in `lars-buffers':

("2019-06-30T20:50:37" 1 #<buffer  *server news.gmane.org nntp  *Async Prefetch Article**> "")

and the next entries were from a successful connection.  And this is
after letting it hang for, say, ten seconds before `C-g'-ing it, so
there should be hundreds of elements there, since accept-process-output
is supposed to return after 0.05s.

What's in the buffer after `C-g' was, both times:

----

200 news.gmane.org InterNetNews NNRP server INN 2.6.1 ready (posting ok)^M

Process nntpd<3> connection broken by remote peer

----

I'll keep poking at this, but this is pointing at
`accept-process-output' having some kind of problem...  But we'll see;
perhaps these two hangs weren't typical...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no