GNU bug report logs - #45821
28.0.50; Add UDP support for Emacs on Windows

Previous Next

Full log

Message #28 received at 45821 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 45821 <at> debbugs.gnu.org
Subject: Re: bug#45821: 28.0.50; Add UDP support for Emacs on Windows
Date: Mon, 04 Oct 2021 19:47:43 +0200

>>>>> On Mon, 27 Sep 2021 19:45:22 +0200, Robert Pluim <rpluim <at> gmail.com> said:

>>>>> On Mon, 27 Sep 2021 18:47:47 +0200, Robert Pluim <rpluim <at> gmail.com> said:
    Robert> Iʼve resurrected this patch, it seems to be working nicely. Adding a
    Robert> lisp-level control variable seems more trouble than itʼs worth, I
    Robert> think the risk of breaking stuff on all platforms is higher than
    Robert> that of breaking stuff on Windows.

    Robert> Are we too late for emacs-28?

    Robert> Although Iʼve broken TLS connections in the process (but not http), so
    Robert> maybe weʼre too late.

I did some more debugging on this. What's happening is that in
'wait_reading_process_output', when calling gnutls_try_handshake,
weʼre exceeding GNUTLS_EMACS_HANDSHAKES_LIMIT. That has a value of
6000, so my suspicion is that because the reader_thread no longer
actually reads, but just calls pfn_WSAEventSelect,
'wait_reading_process_output' just spins. With the original code,
weʼre calling gnutls_try_handshake perhaps 2 or 3 times, so I donʼt
understand why the new code behaves so differently (and this
definitely won't make emacs-28).

Interestingly: only 'M-x eww RET https://www.gnu.org' causes
this. 'M-x eww RET https://www.google.com' works fine with both
implementations.

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.