bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24201: 25.1.50; TLS connections sometimes hang


From: Lars Ingebrigtsen
Subject: bug#24201: 25.1.50; TLS connections sometimes hang
Date: Fri, 05 Jul 2019 14:59:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]