lkml.org 
[lkml]   [2005]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread_Id
J.A. Magallon wrote:

>On 07.14, RVK wrote:
>
>
>>Ian Campbell wrote:
>>
>>
>>
>>>On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
>>>
>>>
>>>
>>>
>>>>Ian Campbell wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>What Arjan is saying is that pthread_t is a cookie -- this means that
>>>>>you cannot interpret it in any way, it is just a "thing" which you can
>>>>>pass back to the API, that pthread_t happens to be typedef'd to unsigned
>>>>>long int is irrelevant.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?
>>>>
>>>>
>>>>
>>>>
>>>As I understand it, yes, you should never try and assign any meaning to
>>>the values. The fact that you may have been able to find some apparent
>>>meaning under 2.4 is just a coincidence.
>>>
>>>
>>>
>>>
>>>
>>Iam sorry I don't agree on this. This confusion have created only becoz
>>of the different behavior of pthread_self() on 2.4.18 and 2.6.x kernels.
>>And Iam looking for clarifying my doubt. I can't digest this at all.
>>
>>
>>
>
>It is simple: none ever never told you that a pthread_t has nothing to do
>with a pid. pthreads is a standard and portable implementation that
>guarantees you can port _pthread_ code between posix systems. It uses
>an internal opaque type to identify threads, but you should never relay on
>it have nothing to do with pids. The fact that somewhere-in-time-in-some-os
>the pthread_t equals the pid/tid/ etc is just pure chance. If you had
>code relaying on this, it is just broken. Where is stated if pthread_t is
>the tid, an index into a table internal to pthread library, a pointer
>to an struct (mmm, bloken on 64 bits?) or what ?
>
>
>
Understood on pid/tid and thread identifier diffrentiation. The question
now is why pthread_t is typedef as unsigned long ?

>Whatif:
>- you swith kernels and thread library implementation ?
>- you go solaris (it has user level threads ?)
>
>I think one of the sources of the confussion is that:
>- man pages about system calls talk about 'threads', but that should be
> read as 'sibling _processes_ created via clone(CLONE_THREAD) syscall'.
>- man pages about phthreads library also talk about 'threads', but that
> should be read as 'posix threads created via pthread_create'.
>And none guarantees that both 'threads' are the same.
>
>
>
Yes its very important to have clarity in the manuals on this.

>If you just want to use gettid(), don't go further that clone().
>If you use pthread_create(), forget about gettid().
>
>
>
Does the man pages for pthread_create or clone or gettid states this ?

rvk

>(AFAIK ;) )
>
>--
>J.A. Magallon <jamagallon()able!es> \ Software is like sex:
>werewolf!able!es \ It's better when it's free
>Mandriva Linux release 2006.0 (Cooker) for i586
>Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))
>
>
>.
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-15 08:16    [W:0.049 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site