On Tue, 24 Mar 2026 05:47:04 GMT, David Holmes <[email protected]> wrote:
> I'd like to know more about the way this API was being (mis)used to get a > better sense of whether this is just pandering to an extreme case. I agree it would be useful to understand the pattern used in this framework. If it were possible to survey the usages of Thread.setName then I think we would expect to see a lot of usage to set the thread name before starting a thread, in which case there is no pthread_setname_np/prctl(PR_SET_NAME) usage. We would also likely see cases where a thread sets its own name, in which case we would see the syscall. It it possible this framework is trying to put additional transient context in the thread name for diagnosability purposes, e.g. transaction ID, URL ?? It would be useful to know if setting the OS thread name is useful or not. I assume it will depend on what diagnosability tools are used by folks supporting these environments. Folks familiar with the JDK troubleshooting tools will see the thread name in thread dumps and elsewhere. Folks that come at it from the "sys admin" viewpoint like the OS thread names. There may be a case for a XX option to disable setting the OS name, but I think we need more context to know what there is an issue in the first place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30374#issuecomment-4115955990
