bug#22789: 25.1.50; In last master build https connections stop working

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Alain Schneble <a.s@realize.ch>,  j_l_domenech@yahoo.com,  
> 22789@debbugs.gnu.org
> Date: Tue, 01 Mar 2016 16:17:13 +1100
> 
> All the immediate ideas I have to ensure we have a timer that triggers
> `wait_reading_process_output' now and then when we have processes
> waiting for DNS or to complete TLS negotiation remind me too much of
> reference counting.  There's always an off by one error or a race
> condition when counting.  :-)
> 
> But, basically, we have to have a way to say "I'm starting this stuff
> now, and the timer should continue to trigger every 50ms until I'm
> done".  And then stop when they're all done...

You don't actually need a timer, since there's nothing you'd need the
timer function do.  What you want is a way to ensure the loop in
wait_reading_process_output continues to run, without becoming stuck
for too long in a call to 'pselect', for as long as there are process
objects waiting for this async stuff to complete; and you want to make
sure this happens even if Emacs doesn't get any events from the
window-system, the keyboard, the subprocesses, whatever.

Timers solve this problem for you because that loop computes the
timeout for the 'pselect' call such that the timeout ends when the
next timer expires.  For example, the blink-cursor timer causes the
timeout to be at most 0.5 sec.  Indirectly, this causes the loop to
crank one more iteration, which helps you, because Emacs then gets an
opportunity to check on the status of the TLS negotiation etc.  The
timer itself is redundant; its effect on the loop is what you want.

So what you can do instead of launching a timer is this: as long as
some process waits for some sync stuff to complete, reduce the timeout
with which we call 'pselect' to some reasonably small value, like half
a second or maybe 0.25 sec.  This will ensure the loop doesn't stop as
long as we wait for at least one such connection.  (This will need a
simple logic to not exit the loop too early; see the variable
timeout_reduced_for_timers for a similar logic we employ already for
timers.)