| msg66882 - (view) |
Author: Irmen de Jong (irmen)  |
Date: 2008-05-15 21:49 |
| I've ran into a problem where it would be very nice to be able to tell the tread.get_ident() of a given threading.Thread object. Currently, when creating a new Thread object, there is no good way of getting that thread's get_ident() value. I propose adding the get_ident() value as a publicly accessible field of every threading.Thread object. |
|
|
| msg67248 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-23 15:29 |
| > Currently, when creating a new Thread object, there is no good way of > getting that thread's get_ident() value. Well, how about doing it at the beginning of its run() method, e.g. in a Thread subclass: class MyThread(threading.Thread): def run(self): self.thread_ident = thread.get_ident() threading.Thread.run(self) # or any other stuff Also, I don't think get_ident() is often useful when using the Threading module, since you can just use the id() of the current Thread object instead. |
|
|
| msg67274 - (view) |
Author: Irmen de Jong (irmen) |
Date: 2008-05-23 23:26 |
| Adding it in the run method would only work for threads that I create in my own code. The thing is: I need to be able to get the tread identification from threads created by third party code. So I cannot rely on that code putting it in the thread object themselves like that. Hence my wish of letting the standard library module take care of it. And using the id() of the current thread object has a rather obscure problem. I was using it as a matter of fact, until people reported problems in my code when used with certain atexit handling. (Sometimes the wrong id() is returned). Because of that I wanted to switch to the more low-level thread.get_ident() identification of different threads, because that is supposed to return a stable os-level thread identification, right? |
|
|
| msg67310 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-05-24 22:20 |
| Well, it's true that get_ident() will always give you a reliable number while currentThread() can play dirty games on you at shutdown. The thing is the Thread object is dereferenced before the OS thread actually terminates, so it may be that a Python callback is called by some C code in those last moments and gets the wrong answer from currentThread() (because currentThread() returns a new dummy thread when it can't find a Thread object corresponding to the get_ident() value). So finally your request sounds quite reasonable :-) |
|
|
| msg67312 - (view) |
Author: Gregory P. Smith (gregory.p.smith) * |
Date: 2008-05-24 22:47 |
| This seems like a useful addition and is easy enough. Patch with tests and documentation attached. Unless I hear objections I will commit it to trunk later this week. Patch available for review here: http://codereview.appspot.com/1301 |
|
|
| msg67314 - (view) |
Author: Irmen de Jong (irmen) |
Date: 2008-05-24 23:40 |
| Thanks Gregory, for taking the time to make a patch. |
|
|
| msg67619 - (view) |
Author: Gregory P. Smith (gregory.p.smith) * |
Date: 2008-06-01 23:49 |
| committed to trunk r63882 for inclusion in 2.6. |
|
|