The always funny Alberta Tech has a video “Linked Lists Aren’t Real” which I stumbled upon again recently. That touched on a topic I long wanted to write about, so here we go (made possible by the curl summer of bliss).

The Trouble with Linked Lists

As an introductory topic for computer science beginners epic journey into data structures they are easy to grasp. You have an anchor (The List) and next pointers (The Elements) which you can chain together. The anchor points to the first element, each element points to the next. NULL or nil or None (whatever your language has as an absent value) terminate the list.

During the curl summer of bliss I found some breathing room again to look at a favourite topic of mine: performance.

Below you see how recent curl versions behave when downloading 20 thousand times the same 10KB resource from a local Apache httpd via HTTP/2. In the top part you see the speed in requests per second (higher is better) and in the lower part the memory in use during this is shown (lower is better).

(Disclaimer: I speak from my maintainer perspective. I have no deep insights into deployment and operations. My very personal opinions here.)

Also called coordinated vulnerability disclosure states on wikipedia that:

a vulnerability disclosure model in which a vulnerability or an issue is disclosed to the public only after the responsible parties have been allowed sufficient time to patch or remedy the vulnerability or issue.

which sounds very sensible. The intention clearly is to keep the bad guys in the dark until the good guys had time to patch everything.

In part I, part II and part III I talked about the changes to DNS resolution in curl and why we do them. In this post I cover the performance/resources related changes in the threaded resolver. This is the most common build option, deployed by many distros.

Previously…

In curl 8.19.0 and earlier, the “threaded resolver” means libcurl starts a new thread to call getaddrinfo(), as I explained in part II. In addition, it opens a socketpair (or eventfd on modern linux), so the resolver thread can notify the “main” thread it’s done.

In part I and part II I talked about the changes to DNS resolution in curl and why we do them. In this post I cover the difference and changes in synchronous vs asynchronous resolution. Which matter for Happy Eyeballs v3 (HEv3) and Encrypted Client Hellos (ECH).

Sync/Async, Old and New

Out of all the DNS options I described in part II, the most compatible and most deployed one is getaddrinfo().

Sync, no threads or c-ares