-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Set names to runtime internal threads #75113
Conversation
Tagging subscribers to this area: @tommcdon Issue DetailsIt gives names to internal thread so that they can be distinguished easier when debugging, triaging, and/or profiling.
|
Note that thread names are limited to 15 chars on Linux and perhaps macOS and FreeBSD, so all names must be distinguishable in the first 15 chars. With ".NET " that leaves 10. The ones in this PR seem fine but we have not done this in some places eg: runtime/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs Line 1358 in bcd44bf
runtime/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.GateThread.cs Line 244 in bcd44bf
runtime/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WaitThread.cs Line 190 in 6251d49
Are not distinguishable. Windows from memory has a higher limit, so places in Windows specific code should be fine. Might be worth follow up cleanup. IMO I'd keep the prefix but use some contracted form like ".NET TPool Wait" We maybe should Assert in the PAL for > 15 |
Mac builds broke
|
Thank you for the note. runtime/src/coreclr/pal/src/thread/thread.cpp Lines 94 to 100 in 2dcd5bf
runtime/src/coreclr/pal/src/thread/thread.cpp Lines 1662 to 1668 in 2dcd5bf
|
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.GateThread.cs
Outdated
Show resolved
Hide resolved
Test failures seem infrastructural... failed to load CLR, entry point not found, etc |
The failures looks like a real problem with the change to me. |
@danmoseley @jkotas Would you merge this please? |
The tests are failing due to changes in this PR |
|
Thank you Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
931ecd1
to
27bfcf1
Compare
27bfcf1
to
e4f8691
Compare
@jkotas I think it's ready. .NET CI is nice. :) |
1a315f7
to
2ee5c1b
Compare
Now it looks like this on Linux. (gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7a4c3c0 (LWP 619311) "corerun" __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737348158400) at ./nptl/pthread_kill.c:44
2 Thread 0x7ffff6afc640 (LWP 619314) "corerun-ust" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
3 Thread 0x7ffff62fb640 (LWP 619315) "corerun-ust" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
4 Thread 0x7ffff5afa640 (LWP 619316) ".NET SynchManag" 0x00007ffff7b65d7f in __GI___poll (fds=0x0, nfds=0, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
5 Thread 0x7ffff52f9640 (LWP 619317) ".NET EventPipe" 0x00007ffff7b65d7f in __GI___poll (fds=0x7fff70008f40, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
6 Thread 0x7ffff4ad3640 (LWP 619318) ".NET DebugPipe" 0x00007ffff7b61764 in __libc_open64 (file=0x55555559fa44 "/tmp/clr-debug-pipe-619311-18359507-in", oflag=0) at ../sysdeps/unix/sysv/linux/open64.c:41
7 Thread 0x7fffe7fff640 (LWP 619319) ".NET Debugger" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555555645670) at ./nptl/futex-internal.c:57
8 Thread 0x7fff77cc4640 (LWP 619320) ".NET Finalizer" __futex_abstimed_wait_common64 (private=1432321820, cancel=true, abstime=0x7fff77cc30b8, op=137, expected=0, futex_word=0x555555666360) at ./nptl/futex-internal.c:57
9 Thread 0x7fffe6e02640 (LWP 619321) ".NET SigHandler" __GI___libc_read (nbytes=1, buf=0x7fffe6e01e47, fd=33) at ../sysdeps/unix/sysv/linux/read.c:26 |
9a1fd19
to
b3b156d
Compare
b3b156d
to
1de0103
Compare
Thank you! |
Thank you for your kind reviews and advice. |
It gives names to internal threads so that they can be distinguished easier when debugging, triaging, and/or profiling.