Set thread pool thread name just based on string pointer check. #16637
Conversation
|
@vargaz could you please review that |
|
@monojenkins build OS X x64 Hardened Runtime |
mono/metadata/object-internals.h
Outdated
There was a problem hiding this comment.
Yes we could. It is a reasonable idea, but yes, removable.
It predates the ability to just do the pointer compare.
There was a problem hiding this comment.
To be clear, w/o this PR, it is used. This PR replaces the use.
There was a problem hiding this comment.
IMHO it should be removed if it's unused. We can always bring it back from history if necessary. Otherwise the change LGTM.
There was a problem hiding this comment.
I'd be resolving merge conflicts in configure.ac every few days for months, had I made that change.
There was a problem hiding this comment.
I’ll remove it today. Hopefully without having it sit months longer.
mono/metadata/threadpool.c
Outdated
There was a problem hiding this comment.
Given this duplicates knowledge from set_constant, merits a comment or a helper macro/function.
There was a problem hiding this comment.
I added a funny named flag to centralize the knowledge.
|
@monojenkins build monolite |
9525558 to
22c1e33
Compare
|
@monojenkins build failed |
1 similar comment
|
@monojenkins build failed |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 16637 in repo mono/mono |
|
Azure Pipelines bot triggering is broken, it was already reported upstream by the dotnet people. |
When the generation-based solution went in, there were not yet constant thread names, so a pointer based approach could fail due to reuse. We can do slightly simpler now.
Remove the duplicated knowledge of how to set a constant and put it behind a funny sounding but perhaps reasonable flag. Revise corlib version.
22c1e33 to
9a7d1bc
Compare
|
@monojenkins build monolite |
|
@jaykrell can you please rebase this PR to master? |
|
@monojenkins build deb with monolite |
|
@monojenkins build |
| MonoSetThreadNameFlag_Permanent = 0x0001, | ||
| MonoSetThreadNameFlag_Reset = 0x0002, | ||
| MonoSetThreadNameFlag_Constant = 0x0004, | ||
| MonoSetThreadNameFlag_RepeatedlyButOptimized = 0x0008, |
There was a problem hiding this comment.
I don't like this name.
Some might shorten it to "Fast" (the "optimized" part, omitting the "repeatedly" part).
I don't like that either, popular but vague.
I couldn't come up with anything else.
It could also be, instead of the behavior, the user -- "ThreadPoolWorker".
But I just pushed past the analysis/naming paralysis. :)
…/mono#16637) * Set thread pool thread name just based on string pointer check. When the generation-based solution went in, there were not yet constant thread names, so a pointer based approach could fail due to reuse. We can do slightly simpler now. * Remove the generation field which is no longer needed. Remove the duplicated knowledge of how to set a constant and put it behind a funny sounding but perhaps reasonable flag. Revise corlib version. Commit migrated from mono/mono@2129ac6
When the generation-based solution went in, there were not
yet constant thread names, so a pointer based approach could fail
due to reuse. We can do slightly simpler now.