bug#24201: 25.1.50; TLS connections sometimes hang

[Lars Ingebrigtsen]

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.

>> 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 you say "and we get the data".  So what am I missing here?

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.

The gdb-ing I did earlier seemed to say that this was not the case
(i.e., that it was looping in that loop above there), but Emacs
apparently behaves differently when stepping through in gdb than when
it's not...

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