Strangely, the initial name of the WorkerThreads is one higher than their (zero-based) index in the WSTP

I have some recollection that the nameIndex and WSTP index are kind of independent, but I haven't really thought about it. See #2687 (comment), sorry if this is just noise :)

Hm, that's interesting. I'm not sure (any more) what was the original intention. I thought, that working workers should have the WSTP index in their names, because when a cached thread becomes a worker, it is carefully set to that: https://github.com/typelevel/cats-effect/blob/series/3.x/core/jvm/src/main/scala/cats/effect/unsafe/WorkerThread.scala#L845.

But apparently this is not true for new (replacement) workers. So now I made it so (my 2 new commits).

It is completely possible, that I imagined this whole "name should have the WSTP index" thing. But seeing 2 threads with the same name in visualvm is pretty confusing (it did happen, that's how I found this). So this PR should fix that...

It just occurred to me, that it's completely possible (even likely), that the call in init is the wrong one (should be setName(s"$prefix-$nameIdx")), and the other 2 places I've "fixed" in this PR should be left alone. That would also fix the duplicate name problem (I think).

My approach (currently in this PR) has the advantage of having the WSTP workers name end with their WSTP index.

The (probably) originally intended approach has the advantage of threads having a stable postfix in their names, and it's just the prefix which changes when they move in/out of the WSTP.

The (probably) originally intended approach has the advantage of threads having a stable postfix in their names, and it's just the prefix which changes when they move in/out of the WSTP.

Yeah, fwiw I like the sound of this.

WSTP index did not need to be the same as the name index, but if it helps debugging, go for it.