On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:Its not a joke its a confusion created by the thread identifier.
it doesn't return a number it returns a pointer ;) or a floating pointHahaha......common. Please clarify following....
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.
I'm missing the joke
So then what is the meaning of that typedef and why its still there ?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.
Other implementations are allowed to use different types for this. InI 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.
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).
.