bug#24201: 25.1.50; TLS connections sometimes hang

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  24201@debbugs.gnu.org,  
> eggert@cs.ucla.edu
> Date: Thu, 04 Jul 2019 15:04:54 +0200
> 
> 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.

There's also this:

      /* Wait till there is something to do.  */

      if (wait_proc && just_wait_proc)
        {
          if (wait_proc->infd < 0)  /* Terminated.  */
            break;
          FD_SET (wait_proc->infd, &Available);
          check_delay = 0;
          check_write = 0;
        }

In your case, wait_proc is non-NULL.

Can you tell which of the various conditions cause
accept-process-output to return after a timeout when you apply the
patch to network-stream.el?  Then we'd know for sure which part helps
avoid the loop when JUST-THIS-ONE is non-nil.

But what I'm missing is some description of the traffic that happens
on the wire.  Is the remote responding or isn't it, and if not, then
do we have any idea why?