Compared to MySQL, MariaDB has only few single purpose threads. There is timer thread, there is page cleaner thread, there is a main thread, that accepts connections, and nothing interesting otherwise. there can be a bunch of background threads, from a threadpool, that handle innodb background work, and a bunch of foreground threads, that handle user queries ( from thread pool or not). I'm wondering if you can gain much from such info

I'd really be happy to know if CPU is used by a specific foreground user thread, some of slave applier threads or some background InnoDB thread.

left a few notes in https://github.com/MariaDB/server/commit/7e53e7729bf58a0e806424d538ed086f44304c1b

May be, let's avoid multiplying entities without a necessity?
There's performance schema, it already has names for all threads. For example

static PSI_thread_info all_mysys_threads[]=

{

  { &key_thread_timer, "statement_timer", PSI_FLAG_GLOBAL}

};

the thread is started as

  if (mysql_thread_create(key_thread_timer, &timer_thread, &thr_attr,

                          timer_handler, NULL))

so in mysql_thread_create() performance schema can use pthread_setname_np() or whatever for the return value of pthread_create(), setting the name for the new thread. And users will see the same name in ps and in select * from performance_schema.threads. Less confusion.

serg, this does not work.

• You assume the name can be always set from outside. It can't, portably. On macOS, our supported platform, there is no thread handle or ID that you can use this pthread_setname_np() with.
• It can make sense, to change thread name, sometimes. For example, if the connection id is 10, one might want, in debug version say, change name of the thread to conn_10. Makes it easier to find your connection

• Not all threads are created with mysql_thread_create. There are some with std::thread.
  There are some that are created by the OS-controlled threadpool , e.g on Windows where OS
  takes over the thread lifecycle. I'd like to have a thread name nonetheless, to distinguish between connection thread pool and Innodb's background threads.

Thread names are for debugging and profiling, and that's it.

I thought another option could be to set the name inside the thread, but have a DBUG_ASSERT that it matches the name in perfschema. Then it'll still be "one entity" from the user point of view, even if we'll specify the name in two places (or one can #define STATEMENT_TIMER_THREAD_NAME and use it everywhere).

As for many threads with the same name, I thought it'd be useful to print them like, say, "statement_timer:1234" where "1234" is, ideally, the id in the performance_schema.threads.

The point is still to show not some arbitrary info but something that correlates with other information sources. For example, one can use ps to find the thread that takes 100% CPU and then use performance_schema to find out more.

serg I sort-of did this verification in the last patch. Not sure it is a good idea, and strictly speaking we can't have the very same entity from the user's point of view.

Because, Linux does not accept long names (where long is > 15 characters), one can't have thread names like "thread/innodb/page_cleaner", you can't even have names like 'innodb/page_cleaner'. Only names like 'page_cleaner' are possible, due to Linux limitations.

I thought a bit about many threads with the same name, I actually would prefer them to have the same name by default (unless maybe an option is set).
The profiler I use does a nice aggregation based on thread names, so I can figure out how much CPU foreground threads are using, and how much background ones, I'd rather not lose it. Besides, already some work was done to show OS thread id and what not in processlist and performance_schema.threads, this can help find thread during debugging

Thanks. That explains why firefox names threads like

AudioIP~ver RPC

Backgro~ #51598

BgIOThr~ol #600

CanvasRenderer

Compositor

Cookie

DNS Res~r #1879

DNS Res~r #1882

DNS Res~r #1883

Agree about not appending numeric ids, not even for your profiler sake, but simply because the length is such a scarce resource, we shouldn't waste it on something that can be stored elsewhere, such a thread id.

Then what about — the same name as the last component of name in perfschema. Assert if such a last component is longer than 15 characters, it'll limit our imagination a bit, but I'm sure we'll manage.

PERFORMANCE_SCHEMA.THREADS has columns NAME and OS_THREAD_ID, they should match the values from

ps H -o tid,comm

("match" in the above sense. for tid it's "equal", for "comm" it's "last component of")