Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix worker thread name index #3591

Merged
merged 4 commits into from
May 3, 2023

Conversation

durban
Copy link
Contributor

@durban durban commented May 2, 2023

Strangely, the initial name of the WorkerThreads is one higher than their (zero-based) index in the WSTP (i.e., io-compute-1, io-compute-2, ... instead of io-compute-0, io-compute-1, ...). After a worker is converted to a blocker, and then returns to the WSTP, its name will have the correct index (i.e., zero-based). Confusingly, this can cause two worker threads to have the same name. E.g., originally io-compute-2 (with index 1) becomes io-compute-1, but there could be another io-compute-1 (with index 0).

This PR fixes this inconsistency.

@armanbilge
Copy link
Member

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 :)

@durban
Copy link
Contributor Author

durban commented May 3, 2023

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...

@durban
Copy link
Contributor Author

durban commented May 3, 2023

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.

@armanbilge
Copy link
Member

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.

@vasilmkd
Copy link
Member

vasilmkd commented May 3, 2023

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

Copy link
Member

@djspiewak djspiewak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely a fan of anything that improves introspectibility.

@djspiewak djspiewak merged commit 7cd4523 into typelevel:series/3.4.x May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants