Here are the 2 patches that can be applied, in order:
- 0001 -> the original patch from the email thread, that I used
- 0002 -> the additions that I made locally
Note: TLS mostly works, but I’ve observed some weird behavior in the process list for EWW
- It almost feels like sometimes we hit snags in navigating to some HTTPS endpoints because the existing connections never get closes
- I think we need to make some investigations/ changes to the socket lifetime / close behavior to fix the class of issues we are seeing in EWW, where sometimes the page load hangs, and yes, you can load it after a couple of refreshes (‘g’ key binding) but then you see something really interesting if you take a look at the process list
- You will notice that some of the connection never close (properly) and hang around!
- If anyone has any good pointers of what are good functions to look at, please let me know; I will take a look at this later in the day, and navigate the reader thread and everything around it..
p.s. I didn’t find an obvious way of merging the two patches in magit, hence the 2 individual patches
😊 – I guess I can just rebase the commits into one..
Sent from Mail for Windows
From: Robert Pluim
Sent: Tuesday, January 3, 2023 12:51 AM
To: Alex Matei
Cc: Eli Zaretskii;
45821@debbugs.gnu.org
Subject: Re: bug#45821: Emacs UDP support on Windows
>>>>> On Mon, 2 Jan 2023 22:56:04 +0000, Alex Matei <matei.alexandru@live.com> said:
Alex> Thanks for the tips with logging!
Alex> I think I found the fix (at least for one of the issues?)
Alex> Please see the attached patch/diff for the fix.
Alex> The code will always ignore (aka ‘eat’) one character if the file
Alex> descriptor had the least significant bit set (0x1, so this would mean
Alex> for any file descriptor with READ flag set)
Alex> [cid:image004.png@01D91EBA.5498F140]
Hmm, my local version already had that fixed, so I guess I posted the
wrong patch to the bug. But I still think you found a fix (see below)
Alex> Based on operator precedence rules, FILE_SOCKET == 0 will be evaluated
Alex> first (before &) , resulting in 0, which would effectively cause the
Alex> condition to always be false
Alex> This behavior can be observed when executing a call to
Alex> ‘(async-shell-command)’ (-> file descriptor flags 0x191) on a build
Alex> with the patch vs one without the patch applied (see below, attached
Alex> image)
Alex> * My suspicion is that this behavior is similar to what TLS was
Alex> experiencing but just easier to reproduce (note: there might other
Alex> issues with TLS , but so far, after applying this fix I have not run
Alex> into any other issues)
Alex> [cid:image005.png@01D91EBA.5498F140]
Alex> @Robert Pluim<mailto:rpluim@gmail.com> I don’t know if this was the
Alex> only missing piece, but from all my tests I couldn’t see any issues
Alex> with TLS anymore, and with navigating
https://emea01.safelinks.protection.outlook.com/?url="">
in EWW..
Alex> I wanted to thank you for creating this patch
🙏, and giving me pointers on how to apply and debug it.
Iʼd run the networking portion of our test suite to see if everything
works as intended (you might need to install the GnuTLS cli tools). eg:
cd test
make network-stream-tests
Alex> p.s.
Alex> - The patch also adds STATUS_READ_IN_PROGRESS state for the new
Alex> ‘_sys_wait_readable’ function , based on what the read ahead logic was
Alex> doing already (idk if it is needed, but it is a nice mirror, and a
Alex> good status code to reflect, although I am not convinced anyone cares
Alex> about this state transition..)
I think this is actually the fix, since I added it locally and TLS
started working, but I donʼt understand the code enough to be definite
about that. More testing required
😀
Can you post the full patch just to ensure weʼre all talking about the
same changes? Iʼve attached what Iʼm working from
Robert
--
