search

shanecode / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Get the current thread ID #418

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Proposal
Add a function to get the ID of the calling thread

On what platforms would this be available?
All

Proposed API
get_current_thread_id

Are there existent implementations we can use as an example?
Patch attached

Original issue reported on code.google.com by kunalpar...@gmail.com on 9 Aug 2013 at 10:33

Attachments:

GoogleCodeExporter commented 9 years ago 
Isn't this the same as:

>>> import threading
>>> threading.current_thread()
<_MainThread(MainThread, started 139944996378368)>
>>> threading.current_thread().ident
139944996378368
>>> 

...?

Original comment by g.rodola on 9 Aug 2013 at 10:41

GoogleCodeExporter commented 9 years ago 
It is the same for Windows, but not for POSIX systems.

threading assigns each thread an ID that is retrieved using pthread_self (Ref: 
http://hg.python.org/cpython/file/0152152b09d0/Python/thread_pthread.h#l226). 
pthread_self return type is pthread_id which is an opaque type. So the value 
you see from threading.current_thread is actually the opaque type returned by 
pthread_self which turns out is actually the address of a struct.

Now that works fine if all you need is to differentiate between threads. But 
I'm trying to do some performance analysis for my application. The tools like 
Instruments or Activity Monitor on OS X report the actual thread ID. This 
functions helps tie the threads reported in the tools to the thread in python.

$] python
Python 2.7.3 (v2.7.3:70274d53c1dd, Apr  9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import psutil
>>> psutil.get_current_thread_id()
5444082
>>> import threading
>>> threading.current_thread()
<_MainThread(MainThread, started 140735314661760)>
>>> hex(140735314661760)
'0x7fff7e701180'

Original comment by kunalpar...@gmail.com on 9 Aug 2013 at 6:00

GoogleCodeExporter commented 9 years ago 
Oh I see, the use case would be being able to map current thread's ID with one 
of the items returned by Process.get_threads() right?

Makes sense I'd say, even though Process.get_threads() should probably provide 
more info other than just id and CPU timings ("name" or even "memory" on those 
platforms where this can be retrieved).

Process.get_threads() might also grow an extra "id" parameter so that it can be 
used as such:

>>> p = psutil.Process(pid)
>>> p.get_threads(id=psutil.get_current_thread_id())
thread(id=2539, user_time=0.03, system_time=0.02)
>>>

(note: this leads to questions such as "should we have a custom NoSuchThread 
exception?")

Generally speaking I like the idea, but issue 224 should be fixed first.

Original comment by g.rodola on 9 Aug 2013 at 7:10

GoogleCodeExporter commented 9 years ago 
Yes, that is correct.

This change is independent of the change reported for issue 224. Though it 
would be nice to get issue 224 fixed as well. Whats needed to fix issue 224?

Original comment by kunalpar...@gmail.com on 23 Aug 2013 at 6:04

GoogleCodeExporter commented 9 years ago 
It's not independent from issue 224. 
If on OSX IDs returned by get_threads() are fake then you can't map them with 
p.get_threads(id=psutil.get_current_thread_id()).

Original comment by g.rodola on 24 Aug 2013 at 9:21