Re: Thread_Id

[RVK <rvk@prodmail.net>]

Arjan van de Ven wrote:

>On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
>
>  
>
>>>it doesn't return a number it returns a pointer ;) or a floating point
>>>number. You don't know :)
>>>
>>>what it returns is a *cookie*. A cookie that you can only use to pass
>>>back to various pthread functions.
>>>
>>>
>>>
>>>      
>>>
>>Hahaha......common. Please clarify following....
>>    
>>
>
>I'm missing the joke
>
>  
>
Its not a joke its a confusion created by the thread identifier.

>>SYNOPSIS
>>       #include <pthread.h>
>>
>>       pthread_t pthread_self(void);
>>
>>DESCRIPTION
>>       pthread_self return the thread identifier for the calling thread.
>>    
>>
>
>*identifier*.
>It doesn't give a meaning beyond that, and if you look at other pthread
>manpages (say pthread_join) it just wants that identifier back. If you
>want to attach meaning to a thread identifier, please come up with a
>manpage/standard that actually defines the meaning of it.
>
>  
>
>>bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
>>    
>>
>
>and here you
>1) look at implementation details of your specific threading
>implementation and
>2) you prove that your analysis is wrong since the implementation you
>look at defines it as *unsigned* so it can't be negative. So what your
>app does is clearly wrong even within the implementation you look at.
>
>
>  
>
So then what is the meaning of that typedef and why its still there ?

>Other implementations are allowed to use different types for this. In
>fact, I'd be surprised if NPTL and LinuxThreads would have the same
>type... (they'll have the same size for ABI compat reasons of course,
>but type... not so sure).
>
>  
>
I haven't faced the same returns with 2.4.18. So why is it so with 2.6.x 
kernels ? pthread_self() on 2.4.18 was returning the same as gettid() 
with 2.6.x.

rvk

>.
>
>  
>