ansaurus

Question

how to print correctly the handling thread on Windows?

Answer 1

+1 A:

You mean current thread handle in Windows ?

aJ 2010-03-23 06:55:39

thans for your reply. I am getting error when using GetCurrentThread() : error C3861: 'GetCurrentThread': identifier not foundIs there library to include? thanks again

make 2010-03-23 07:33:25

include Windows.h

aJ 2010-03-23 08:07:58

thanks! it doesn't start from 2 as pthread-self on unix-variant. is there anythink else? thanks again

make 2010-03-23 08:23:41

See Giuseppe Guerrini's comment: this doesn't return a real handle; in fact it's quite possible that this will return the same value for all threads (OS implementation detail)

MSalters 2010-03-23 10:59:09

thanks a lot to you all for replies and help!

make 2010-03-23 16:34:39

Answer 2

+2 A:

GetCurrentThread returns a "pseudohandle", not a valid thread handle. You should use "GetCurrentThreadId" instead (or ::GetCurrentThreadId()), and include windows.h, of course.

Giuseppe Guerrini 2010-03-23 08:10:13

thanks for reply. using GetCurrentThreadId doesn't start from 2 as pthread_self on Unix-variant. is there any way to do it? thanks again!

make 2010-03-23 08:22:17

If you need "small IDs" as in the Unix world, I am afraid you have to add some code. A possible way is to mantain a set of zero-based "local IDs" and bind the smallest free number to the threads you create by using the TlsAlloc/TlsSetValue. Not very difficult, but quite annoying, and it works only if all the threads are created by you (i.e. not by some other module you don't control). Bye!

Giuseppe Guerrini 2010-03-23 09:01:31

I'm suspecting that there's a hidden design problem if you're assuming specific values of thread identifiers. If you're on thread 508, then you're not on thread 2. Perhaps the thread ID is used as an array index instead of a hash key?

MSalters 2010-03-23 11:02:51

@MSalters: by a general point of view I agree with you. But in the Unix world there is the quite general rule that the kernel objects handles are allocated by taking always the smallest free index. That's why stdin,stdout and stderr fd are 0,1 and 2. This is true in particular with file descriptors, and it seems, as "make" says, that this rule applies also to threads. Unix developers (me too) are used to advantage of this feature, but of course porting is more difficult.

Giuseppe Guerrini 2010-03-23 11:28:42

I'm familiar with that Unix behavior. But that's not relevant to the question of _printing_ the correct value, is it? That's what the question seems about. If you're on thread 508, you should obviously print 508. Finding a way to print 2 is certainly doable, but senseless.

MSalters 2010-03-23 11:37:41

The problem is "what is the correct value?". I suspect that the "small index" expected was interpreted as a sort of ordinal creation number ("hello, I'm thread #3, i.e. the third one"), something that Windows' thread ID doesn't implement.@make: Is my interpretation correct? Bye!

Giuseppe Guerrini 2010-03-23 11:46:26

@msalters, it seems to me that you are far away from unix. I am a user of unix and on unix-variant, we can control thread as it is mentioned by @giuseppe-guerrini, (in which it is not he case on Windows). thanks a lot to you all for your replies and help!

make 2010-03-23 16:32:58

ansaurus

tags:

views:

answers:

how to print correctly the handling thread on Windows?

related questions