Naming things and the "busy" confusion

[Dridi Boukelmoune]

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