lkml.org 
[lkml]   [2005]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Thread_Id
    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

    >.
    >
    >
    >

    -
    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-14 13:25    [W:0.026 / U:60.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site