From dridi at varni.sh  Fri Oct  3 10:48:37 2025
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 3 Oct 2025 10:48:37 +0000
Subject: Naming things and the "busy" confusion
Message-ID: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>

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

From scan-admin at coverity.com  Mon Oct  6 20:59:38 2025
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Mon, 06 Oct 2025 20:59:38 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <68e42db973e4a_af67d2d6d1028799060cd@prd-scan-dashboard-0.mail>

An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20251006/5cc75063/attachment.html>

From phk at phk.freebsd.dk  Tue Oct  7 10:56:51 2025
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 07 Oct 2025 10:56:51 +0000
Subject: Naming things and the "busy" confusion
In-Reply-To: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
References: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
Message-ID: <202510071056.597AupM8010475@critter.freebsd.dk>

As tempted as I am to go "I have UTF-8 and I'm not afraid to use
it" and rename to "?cluse", I personally see it more as some sort
of distribution mechanism than as a flow-control mechanism.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Tue Oct  7 12:47:39 2025
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 7 Oct 2025 12:47:39 +0000
Subject: Naming things and the "busy" confusion
In-Reply-To: <202510071056.597AupM8010475@critter.freebsd.dk>
References: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
 <202510071056.597AupM8010475@critter.freebsd.dk>
Message-ID: <CABoVN9AZ4G+vkvQrieUqJtsug2dAhu0P012gsdXKm4t6mJF28w@mail.gmail.com>

On Tue, Oct 7, 2025 at 10:56?AM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> As tempted as I am to go "I have UTF-8 and I'm not afraid to use
> it" and rename to "?cluse", I personally see it more as some sort
> of distribution mechanism than as a flow-control mechanism.

I talked about coordination, not flow control. The principle is two
parts of a canal operating at different levels (client vs backend) and
the sluice coordinating the transit of boats (body bytes) from one
level to the other. Sure that involve some amounts of flow control,
but that's just means to an end.

From phk at phk.freebsd.dk  Tue Oct  7 13:12:51 2025
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 07 Oct 2025 13:12:51 +0000
Subject: Naming things and the "busy" confusion
In-Reply-To: <CABoVN9AZ4G+vkvQrieUqJtsug2dAhu0P012gsdXKm4t6mJF28w@mail.gmail.com>
References: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
 <202510071056.597AupM8010475@critter.freebsd.dk>
 <CABoVN9AZ4G+vkvQrieUqJtsug2dAhu0P012gsdXKm4t6mJF28w@mail.gmail.com>
Message-ID: <202510071312.597DCpMS011014@critter.freebsd.dk>

--------
Dridi Boukelmoune writes:

> On Tue, Oct 7, 2025 at 10:56=E2=80=AFAM Poul-Henning Kamp <phk at phk.freebsd.=
> dk> wrote:
> >
> > As tempted as I am to go "I have UTF-8 and I'm not afraid to use
> > it" and rename to "=C3=A9cluse", I personally see it more as some sort
> > of distribution mechanism than as a flow-control mechanism.
>
> I talked about coordination, not flow control. The principle is two
> parts of a canal operating at different levels (client vs backend) and
> the sluice coordinating the transit of boats (body bytes) from one
> level to the other. Sure that involve some amounts of flow control,
> but that's just means to an end.

/me inhales deeply...

The reason you need the sluice in the first place is because you
want to control the flow of the river with a dam :-)

But the reason I say it looks more like a "distrbution mechanism"
is that in difference from a sluice, which has one entrace and one
exit, we have one entrance and as many exits as there are clients
streaming this object.

If you want a precise technological prior art, it would be the
"fan-out" points in private telex networks.

For instance a news-providers like Reuters, would have one leased
telex-circuit from London to Paris, where it would be fanned out
to Nice, Strassbourg, Bruxelles (and all the local Paris newspapers),
and from Nice to Torino, and from there to Milano and Rome etc.
forming a tree structure which a minmal (in terms of line costs)
spanning tree.

In North America FCC made a rule that you paid AT&T the cost of the
minimal spanning tree, which is why Knuth's algorithm became so
important so fast.

Both customers and AT&T gamed that FCC rule.

Companies cost-optimized their nets by adding nodes they did not
need in remote hamlets like Hoople, North Dakota, because gave them
a cheaper connection from Chicago to San Francisco etc.

AT&T on the other hand implemented the actual network the way
which made most economic sense to them, which meant that it was
anyones guess what the delay in the total network would be.

That again got reflected in IBM's VTAM which has some very bizarre
configuration options for node timeouts and

...

Sorry, we were taking about what again ?  :-)


If you want a really weird, but precise name suggestion: "Hopper"

That word searches horribly but try "input hopper" or "grain hopper"
and try to generalize yourself.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Tue Oct  7 13:37:25 2025
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 7 Oct 2025 13:37:25 +0000
Subject: Naming things and the "busy" confusion
In-Reply-To: <202510071312.597DCpMS011014@critter.freebsd.dk>
References: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
 <202510071056.597AupM8010475@critter.freebsd.dk>
 <CABoVN9AZ4G+vkvQrieUqJtsug2dAhu0P012gsdXKm4t6mJF28w@mail.gmail.com>
 <202510071312.597DCpMS011014@critter.freebsd.dk>
Message-ID: <CABoVN9BCzY_aX+UPbrcX8BZxD2NhOcnN7kxEAoAOmNxOPYLh5Q@mail.gmail.com>

On Tue, Oct 7, 2025 at 1:12?PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> Dridi Boukelmoune writes:
>
> > On Tue, Oct 7, 2025 at 10:56=E2=80=AFAM Poul-Henning Kamp <phk at phk.freebsd.=
> > dk> wrote:
> > >
> > > As tempted as I am to go "I have UTF-8 and I'm not afraid to use
> > > it" and rename to "=C3=A9cluse", I personally see it more as some sort
> > > of distribution mechanism than as a flow-control mechanism.
> >
> > I talked about coordination, not flow control. The principle is two
> > parts of a canal operating at different levels (client vs backend) and
> > the sluice coordinating the transit of boats (body bytes) from one
> > level to the other. Sure that involve some amounts of flow control,
> > but that's just means to an end.
>
> /me inhales deeply...

Yes, bikeshed requires energy.

> The reason you need the sluice in the first place is because you
> want to control the flow of the river with a dam :-)
>
> But the reason I say it looks more like a "distrbution mechanism"
> is that in difference from a sluice, which has one entrace and one
> exit, we have one entrance and as many exits as there are clients
> streaming this object.
>
> If you want a precise technological prior art, it would be the
> "fan-out" points in private telex networks.
>
> For instance a news-providers like Reuters, would have one leased
> telex-circuit from London to Paris, where it would be fanned out
> to Nice, Strassbourg, Bruxelles (and all the local Paris newspapers),
> and from Nice to Torino, and from there to Milano and Rome etc.
> forming a tree structure which a minmal (in terms of line costs)
> spanning tree.
>
> In North America FCC made a rule that you paid AT&T the cost of the
> minimal spanning tree, which is why Knuth's algorithm became so
> important so fast.
>
> Both customers and AT&T gamed that FCC rule.
>
> Companies cost-optimized their nets by adding nodes they did not
> need in remote hamlets like Hoople, North Dakota, because gave them
> a cheaper connection from Chicago to San Francisco etc.
>
> AT&T on the other hand implemented the actual network the way
> which made most economic sense to them, which meant that it was
> anyones guess what the delay in the total network would be.
>
> That again got reflected in IBM's VTAM which has some very bizarre
> configuration options for node timeouts and
>
> ...
>
> Sorry, we were taking about what again ?  :-)
>
>
> If you want a really weird, but precise name suggestion: "Hopper"
>
> That word searches horribly but try "input hopper" or "grain hopper"
> and try to generalize yourself.

But then we are completely out of the "stream" lexical field. If I
wanted a different approximation I would have suggested something like
demux or whatever.

The points remain:

- OC_F_BUSY has a specific role and meaning
- the name busyobj aka bo is misleading, being unrelated
- boc is misleading on two different levels

If you want your boat to fan out, call it a quantum boat that may take
any fork on the stream after passing the hyper-sluice, and only a
cosmic VDP can tell when it tries to observe the boat.

I'll take the direction this thread took as a no on renaming anything
and a vote in favor of entertaining a comfortable confusion.

From phk at phk.freebsd.dk  Tue Oct  7 14:11:53 2025
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 07 Oct 2025 14:11:53 +0000
Subject: Naming things and the "busy" confusion
In-Reply-To: <CABoVN9BCzY_aX+UPbrcX8BZxD2NhOcnN7kxEAoAOmNxOPYLh5Q@mail.gmail.com>
References: <CABoVN9B1Fi5tZSoPkMH5o9SoUuF16rRwcj-Liu_U9Covx932=Q@mail.gmail.com>
 <202510071056.597AupM8010475@critter.freebsd.dk>
 <CABoVN9AZ4G+vkvQrieUqJtsug2dAhu0P012gsdXKm4t6mJF28w@mail.gmail.com>
 <202510071312.597DCpMS011014@critter.freebsd.dk>
 <CABoVN9BCzY_aX+UPbrcX8BZxD2NhOcnN7kxEAoAOmNxOPYLh5Q@mail.gmail.com>
Message-ID: <202510071411.597EBrQB011230@critter.freebsd.dk>

Dridi Boukelmoune writes:

> I'll take the direction this thread took as a no on renaming anything
> and a vote in favor of entertaining a comfortable confusion.

I'm actually on the same page as you with respect to fixing the confusion,
but we need to find a name which works.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From scan-admin at coverity.com  Mon Oct 13 11:50:11 2025
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Mon, 13 Oct 2025 11:50:11 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <68ece7731d9fb_22bde2e88779c99a07186d@prd-scan-dashboard-0.mail>

An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20251013/e1d188d8/attachment.html>

From scan-admin at coverity.com  Mon Oct 20 19:20:49 2025
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Mon, 20 Oct 2025 19:20:49 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <68f68b913fa1e_279842d0ec52c599c91385@prd-scan-dashboard-0.mail>

An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20251020/18c11e45/attachment.html>

From scan-admin at coverity.com  Mon Oct 27 14:41:09 2025
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Mon, 27 Oct 2025 14:41:09 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <68ff84849f3ee_92c782d0ec52c599c91394@prd-scan-dashboard-0.mail>

An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20251027/a4852d9b/attachment.html>