Peter Dimov wrote:
The demand for thread ID's come from the need to _identify_ the thread. In POSIX terms, every operation that takes a pthread_t uses it to identify the thread on which it is supposed to operate.
A quick grep over my header file revealed: the first 5 usages are covered by boost thread pthread_create (pthread_t * tid, ... The ctor pthread_detach (pthread_t tid); The dtor pthread_t pthread_self (void); The default ctor pthread_join (pthread_t thread, ... The join function pthread_equal (pthread_t t1, pthread_t t2); The operator()== The remaining are (not yet) supported by boost thread pthread_cancel (pthread_t thread); pthread_setschedparam (pthread_t thread, ... pthread_getschedparam (pthread_t thread, ... pthread_kill(pthread_t thread, int sig); Do I miss some important usages of pthread_t ? To me it appears that the pthread_t type is simply a C language idiom (kind of a handle). It appears to me as not beeing any different than boost::thread* . Please explain to me where I am wrong in my assumptions. What I think is of more importance is to have a common access point to the thread that can be accessed from inside the thread like a TLS variable, while still be accessible from the outside by a mechansim using something like a thread id as an index. Of course to this end the thread must be indentifyable. But this is not sufficient as I tried to point out. (And also I know of no current implementation of this.) Can you point me please to some other usages of the thread ID beyond the ones above? Roland