PDA

View Full Version : How can I get the thread ID out of QThread



Artschi
24th May 2006, 09:01
Hi everybody,

I'd like to know the tread ID based on a given QThread object. Is there any way to get it?

Note: The given QThread object doesn't correspond with the actual thread; thus CurrentThreadId() would not work.

Thanks

zlatko
24th May 2006, 09:24
Try return QThread::currentThreadId() from actual thread .

Artschi
24th May 2006, 09:57
QThread::currentThreadId() is static and relates to the actual thread but NOT to the thread described by a given QThread object.

zlatko
24th May 2006, 10:30
Yea but try subclass QThread and declare some public method like int getId() in it. And then in this method do return QThread::currentThreadId() i think that it must return correct value of thread id... :rolleyes:
But its just INHO i'm not sure if it will be work :)
If you want you can check am i right ;)

jpn
24th May 2006, 10:37
It does not work. If the getId() is called from another thread, QThread::currentThreadId() would naturally return the identifier of the currently executing thread, which is the caller, not the thread whose method was called.

vratojr
25th May 2006, 09:56
Maybe, I misunsterstood what you want but... Since the manual tells:


Warning: The handle returned by this function is used for internal purposes and should not be used in any application code. On Windows, the returned value is a pseudo-handle for the current thread that cannot be used for numerical comparison.

what about subclassing QThread and pass and int value in the constructor and call THAT value you threadId? After all you can safely use an int getId() function that returns that integer..

Ok, maybe everybody already thought about this but I had to try...;)

iGoo
25th May 2006, 11:25
Maybe, I misunsterstood what you want but... Since the manual tells:

Quote:

Warning: The handle returned by this function is used for internal purposes and should not be used in any application code. On Windows, the returned value is a pseudo-handle for the current thread that cannot be used for numerical comparison.

what about subclassing QThread and pass and int value in the constructor and call THAT value you threadId? After all you can safely use an int getId() function that returns that integer..

Ok, maybe everybody already thought about this but I had to try

On Windows, the returned value is a pseudo-handle for the current thread that cannot be used for numerical comparison.

If so,it behaves as windows api
HANDLE GetCurrentThread(VOID);
you can then call DuplicateHandle to thanslate it to real id.
refer MSDN for dedails.

Artschi
30th May 2006, 09:21
Ups,

thanks for this advice. I missed that part in the documentation.

Sometime it is quite useful to check the manual - even for 'trivial' APIs such as get--Id() :o

But, at the end I'm completely confused :confused: I realized that the thread ID - as provided by QThread::getThreadId() - is not a unique Id/number that is qualified to identify and manage threads on application level, because:

it can't be handed over from one thread context to another
it can't be handed over from one thread context to another
it doesn't uniquely identify running treads by different threads, which would require a numerical comparison of the ID/Handle.
even printing in log statements wouldn't be unique and portable (because of different typedefs).
it isn't possible to recreate/get a specific QThread object based on a ID/Handle

I guess (hope) I'm wrong with this assumption.


If so,it behaves as windows api
HANDLE GetCurrentThread(VOID);
you can then call DuplicateHandle to thanslate it to real id.
refer MSDN for dedails.
I would like not to descent to such platform specific features in application code. Actually, this is one (good) reason to use QT :) But, Thanks anyway.

mr.omid
7th November 2017, 15:34
correct answer here:
proper-use-of-qthread-currentthreadid (https://stackoverflow.com/questions/23452218/proper-use-of-qthread-currentthreadid)

d_stranz
8th November 2017, 03:27
Finally, after 11 1/2 years, @Artschi has his answer. I mean really, don't you check the dates on posts before replying to them?