Remove itt_notify module

[msimberg]

I believe we haven't attempted to use the ITT support in a long time and I don't see ourselves using it in the near future, so I'm proposing to remove it.

I've also updated set_thread_name to set the pthread name. This name shows up in e.g. gdb when doing info threads:

(gdb) info threads
  Id   Target Id                                            Frame
  1    Thread 0x7f901f036980 (LWP 311203) "pika/m/0"        0x00007f901bb1904d in clone3 ()
   from /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6
  2    Thread 0x7f901adfe6c0 (LWP 311210) "mpi_ring_async_" 0x00007f901bb1951e in epoll_wait ()
   from /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6
  3    Thread 0x7f901b5ff6c0 (LWP 311209) "mpi_ring_async_" 0x00007f901bb1951e in epoll_wait ()
   from /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6
  4    Thread 0x7f90193746c0 (LWP 311626) "pika/w/d/0"      0x00007f901ee8f00f in pika::threads::detail::thread_queue<std::mutex, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo>::get_next_thread (
    this=0x7f9008002020, thrd=..., allow_stealing=allow_stealing@entry=true, steal=<optimized out>)
    at /home/mjs/src/pika/libs/pika/schedulers/include/pika/schedulers/thread_queue.hpp:742
  5    Thread 0x7f9018b736c0 (LWP 311627) "pika/w/d/1"      0x00007f901ee8f027 in pika::threads::detail::thread_queue<std::mutex, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo>::get_next_thread (
    this=0x7f9014001ff0, thrd=..., allow_stealing=allow_stealing@entry=true, steal=true)
    at /home/mjs/src/pika/libs/pika/schedulers/include/pika/schedulers/thread_queue.hpp:747
* 6    Thread 0x7f9013fff6c0 (LWP 311628) "pika/w/d/2"      pika_main (vm=...)
    at /home/mjs/src/pika/libs/pika/async_mpi/tests/unit/mpi_ring_async_sender_receiver.cpp:330
  7    Thread 0x7f90137fe6c0 (LWP 311629) "pika/w/p/0"      pika::threads::detail::thread_queue<std::mutex, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo, pika::threads::detail::lockfree_fifo>::wait_or_add_new (this=this@entry=0x7f9000001ff0,
    added=added@entry=@0x7f90137fd678: 0, steal=<optimized out>)
    at /home/mjs/src/pika/libs/pika/schedulers/include/pika/schedulers/thread_queue.hpp:943

The only quirk is that a pthread name can be maximum 15 characters (excluding a null terminator). For this reason I set a "short" thread name for pthreads, such as pika/w/d/2, which denotes a worker thread on the default pool with thread index 2. This shortened name can be ambiguous since it only uses the first character of the thread pool name, but for most purposes this should be unique enough (the default pool is called default, and if an MPI polling pool is used it's called polling). The full thread name can still be accessed with print pika::detail::get_thread_name() on some thread in gdb (in somewhat obscured form, since it's stored in a std::string), e.g.

(gdb) print pika::detail::get_thread_name()
$1 = {_M_dataplus = {<std::allocator<char>> = {<std::__new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffe400a130 "pika/worker-thread/pool:default/global:1/local:1"}, _M_string_length = 48, {_M_local_buf = "0", '\000' <repeats 14 times>,
    _M_allocated_capacity = 48}}

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -0.02% (target: -1.00%)	✅ 92.68% (target: 90.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (b252c0b)	18285	13817	75.56%
Head commit (8cd2180)	18262 (-23)	13796 (-21)	75.54% (-0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#1290)	41	38	92.68%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[rasolca]

pika/worker-thread/pool:default/global:1/local:1

Quick questions:
Why global is present in the name if pika is not distributed?
Isn't it possible to abbreviate the pthread name instead of simply cropping it?
e.g: p/wt/default:1

Unless the pool name is too long it fits in 15 chars

[msimberg]

pika/worker-thread/pool:default/global:1/local:1

Quick questions: Why global is present in the name if pika is not distributed?

They're the global (for the whole runtime) and local (to the pool) thread indices. Nothing to do with distributed, though I see how that might be confusing... E.g. the MPI pool might say pika/worker-thread/pool:mpi/global:15/local:0, because there's only one thread there, but it might be the last worker thread globally (within the process). Suggestions for better names welcome.

Isn't it possible to abbreviate the pthread name instead of simply cropping it? e.g: p/wt/default:1

Unless the pool name is too long it fits in 15 chars

Definitely possible. This was the simplest way of getting them to fit without having to do a lot of custom logic. If I can find a simple way of shortening it I'll consider it for this PR, otherwise I'll probably leave that for "sometime". Not sure it's worth a lot of effort, especially since one can still print the full name manually.

[msimberg]

@rasolca I've updated the short thread names to be pika/<first char of context>/<first char of pool name>/<local thread index>. This is for example pika/w/d/3 for the fourth worker thread on the default pool. I wanted to keep the full pika prefix to distinguish it from other libraries' threads. Only using one character for the pool name can lead to ambiguities of course, but in the default case with the default pool and a potential polling pool the pool names are different. I chose only the local thread index since the pool name can disambiguate the local thread index in the case of multiple pools and is a bit easier to reason about (I think).

What do you think about the change?