bug#24201: 25.1.50; TLS connections sometimes hang

[Lars Ingebrigtsen <larsi@gnus.org>]

I've been poking more at this, and I think there really must be a bug
somewhere in accept-process-output.

With the following patch, connection never hangs:

diff --git a/lisp/net/network-stream.el b/lisp/net/network-stream.el
index 2b3292b71b..cdb33a59f1 100644
--- a/lisp/net/network-stream.el
+++ b/lisp/net/network-stream.el
@@ -376,7 +376,7 @@ network-stream-get-response
 	(goto-char start)
 	(while (and (memq (process-status stream) '(open run))
 		    (not (re-search-forward end-of-command nil t)))
-	  (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))

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.

Now, tracing the logic in wait_reading_process_output is rather...
difficult.  It's an 800 line function with lots of inputs from
everywhere.  But I think this code looks suspicious:

	  if (NILP (wait_for_cell) && just_wait_proc >= 0
	      && timespec_valid_p (timer_delay)
	      && timespec_cmp (timer_delay, timeout) < 0)
	    {
	      if (!timespec_valid_p (now))
		now = current_timespec ();
	      struct timespec timeout_abs = timespec_add (now, timeout);
	      if (!timespec_valid_p (got_output_end_time)
		  || timespec_cmp (timeout_abs, got_output_end_time) < 0)
		got_output_end_time = timeout_abs;
	      timeout = timer_delay;
	    }
	  else
	    got_output_end_time = invalid_timespec ();

This is done only if JUST-THIS-ONE is set.

But...  the timeout stuff is implemented in a very convoluted manner,
with reuse of certain variables that makes what this is trying to
achieve rather opaque. 

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