Greetings, I already mentioned several times my problem with confusion sometimes stemming from misleading names in the code base.
Recently, we dropped the OC_F_BUSY flag that all objcores used to get by default, and only grant this flag to cache misses. During my live review with Nils we had to go over this multiple times, precisely because this whole business (pun intended) is confusing. OC_F_BUSY governs waiting lists. Case in point, waiting list counters are called MAIN.busy_*. The backend fetch task is backed by a struct busyobj. We now have overloaded the meaning of "busy", because struct busyobj's lifetime goes beyond the life of OC_F_BUSY, and a busyobj's purpose is not actually coupled to objhead waiting lists. It's actually struct boc that has (rightfully) grown coupling with waiting lists. More on struct boc below. Since client request tasks are backed by a struct req, maybe backend request tasks should have been backed by a struct bereq. That ship has sailed, and frankly, renaming struct busyobj would only work for me if the result could still be called a "bo" to reduce the blast radius of such a rename. Something like a struct bereq_operator for example, but I found nothing nice and catchy. Now this busyobj operates an objcore usually abbreviated as "oc", and "boc" may sound like a clever bridge between "bo" and "oc", but is actually a misleading name. The role of struct boc is to act as a bridge between a client delivery and a backend fetch, aka streaming. Growing up near a canal with floodgates, I thought the French word "écluse" was a nice abstraction for "streaming coordination". So I'm suggesting renaming struct boc to struct sluice to really distance it from the current false sense of proximity to struct busyobj. And if struct busyobj lands a new bo-compatible name at the same time, you won't see me complain. Best Regards, Dridi _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
