GetCurrentThreadId

Jul 8, 2014 at 10:06 PM
Funny

On Linux GCC: pthread_self() returns a unsigned long
On FreeBSD: returns a pointer to thread.

as solution I have

reinterpret_cast<long>(reinterpret_cast<void*>(pthread_self()));

This line works on both Linux/Debian and FreeBSD.

And why GetCurrentThreadId returns a signed integer, but not unsigned integer?
Coordinator
Jul 8, 2014 at 10:24 PM
pthread_self returns a pthread_t which is an opaque type so it can be different things on different platforms. Is basically treating the address like a long that you mention for FreeBSD going to be ok? Will pthread_self always return the same pointer to the same thread?

The Windows API GetCurrentThreadId returns a DWORD which is an unsigned 32bit integer, you can see here on msdn.

Steve
Jul 8, 2014 at 10:30 PM
Edited Jul 8, 2014 at 10:31 PM
According to link
and

pthread_self -- get the calling thread's ID

Will pthread_self always return the same pointer to the same thread?
I think - yes, it is.
Jul 8, 2014 at 10:41 PM
And on StackOverflow read comments.

As solution I think that reinterpret_cast<long>(reinterpret_cast<void*>(pthread_self())); a good choice,
but in STL we have type thread::id that have thread_id_t or something close to this.
Anyway thread::id type can be represented as hash (something like size_t or unsigned integer 32/64 bit).
Maybe we should use a unsigned integers? and moving to STL version?
Jul 9, 2014 at 8:51 PM
There is a lot of function like pthread_<...>_np(). But such function are not portable and not Unix-compliant.
Also Ubuntu have a "FreeBSD glue" package and etc.

According to answers on StackOverflow and googling it is seems that above reinterpret casts is solution in a uniform way on Linux and BSD.
On Debian and GCC 4.9 all tests are green.
Coordinator
Jul 10, 2014 at 5:50 PM
Ok the thread id has been updated in the development branch.

Thanks,
Steve