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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |