Messages in this thread | | | Date | Fri, 15 Jul 2005 11:39:35 +0530 | From | RVK <> | Subject | Re: 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/
| |