During my summer holiday I’ve mainly been working on making the Emacs networking layer more asynchronous.
To set up a connection, you first have to do DNS resolution, then the TCP three way handshake to set up a socket, and then (if you’re setting up a TLS connection) do the TLS negotiation. Then you can start talking to the server. Up until now, only the middle bit (setting up the socket) has been non-blocking, while the two bits at either end have blocked the main Emacs execution thread.
This means that when eww, the Emacs web browser, wants to download and insert an image into the buffer, the user experience got kinda choppy. The DNS resolution might take a while, and when talking to far away servers, the TLS negotiation certainly took some time.
By adding code based on the glibc getaddrinfo_a library function, the first problem was solved. By calling the gnutls negotiation code from the Emacs event loop, the final problem was solved.
Behold! I’m here reloading a Norwegian web page where most of the images are fetched via https (i.e., TLS):
I’m in Australia, so the networking all the way to Norway is s-l-o-w. Especially since these are TLS connections. Lots of chatter back and forth. As you can see from the cursor movement, there’s no noticable choppiness. Trying the same on this web page before the async patch went it is pretty horrible.
Yay. And it was only a 3200 line diff. Ok, ok, most of that was chopping up lots of 700 line functions into slightly less ridiculously long functions, but eek.
Thanks for your work on this, I’ve been following the discussion but not able to contribute. Blocking DNS requests have been a real pain for me while I’ve been away and using a pretty slow internet connection. Often when I connected to my ~5 IRC servers Emacs ended up effectively freezing for 30seconds+, stopping me do anything else in the mean time.