Finding out thread name

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Finding out thread name

corpaul
Hi,

This is probably very easy to solve but I cannot seem to find how to do this :/

I would like to get the name of a thread from a tid().

So far I have only been able to get the process name (execname()).
I expected the task_execname() to yield the correct name but this didn't seem to work OK.

I would like the information in /proc/$PID/task/TID/comm.

Is there any way I can get this information in systemtap?

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Finding out thread name

Frank Ch. Eigler
corpaul <[hidden email]> writes:

> [...]
> This is probably very easy to solve but I cannot seem to find how to do this
> I would like to get the name of a thread from a tid().
> [...]

It's not as simple as it appears.  When answering a /proc/$$/.../comm
request, the kernel can lock the task list and do such lookups safely
(if slowly).  From the context of an arbitrary systemtap probe, we
can't do that.  (From the context of a custom guru-mode systemtap
script, sure.)

By the way, is this what you tried?  What happened?

probe foo {
      /* do something with */ task_execname(pid2task(pid))
}

- FChE
Reply | Threaded
Open this post in threaded view
|

RE: Finding out thread name

corpaul
This actually works. I was under the impression that /proc/$$/.../comm holds
the python thread name, but this is of course not the case (as the process
was started as 'python', resulting in many threads with that name).

Thanks for clearing the confusion!

--CP

-----Original Message-----
From: Frank Ch. Eigler [mailto:[hidden email]]
Sent: woensdag 8 mei 2013 17:53
To: corpaul
Cc: [hidden email]
Subject: Re: Finding out thread name

corpaul <[hidden email]> writes:

> [...]
> This is probably very easy to solve but I cannot seem to find how to
> do this I would like to get the name of a thread from a tid().
> [...]

It's not as simple as it appears.  When answering a /proc/$$/.../comm
request, the kernel can lock the task list and do such lookups safely (if
slowly).  From the context of an arbitrary systemtap probe, we can't do
that.  (From the context of a custom guru-mode systemtap script, sure.)

By the way, is this what you tried?  What happened?

probe foo {
      /* do something with */ task_execname(pid2task(pid)) }

- FChE