[lkml]   [2004]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Using getpid() often, another way? [was Re: clone() <-> getpid() bug in 2.6?]

    Ah, the stack. Yes, I think that will work. You see, the functions that
    need this test
    always take a pointer to a struct that holds all the thread info called
    'mon'. That info is the pid of the
    thread , the ptr to the stack mmap'd and the size of the stack, I think
    I can change the test to:


    /* if address of the stackvar is OUTSIDE the stack of handler
    thread, then
    you are not running this function from the handler thread */
    if ( &stackvar < mon->handler_q.thread->stack ||
    &stackvar > mon->handler_q.thread->stack +
    mon->handler_q.thread->stacksize - 1) {

    fprintf(stderr, "bad, bad, bad!\n");



    Would that work? If so, that is nice because no syscall.

    Robert Love wrote:

    >On Sun, 2004-06-06 at 11:38 -0400, Russell Leighton wrote:
    >> Given a code library with some exported functions which CAN be
    >>executed outside a particular thread and others that MUST be executed in
    >>a particular thread, how can I efficiently prevent or trap using of
    >>these functions outside the proper execution context?
    >Are you sure you cannot use pthreads? The new implementation (NPTL) has
    >a lot of improvements, including saner signal handling behavior.
    >If not, you probably are out of luck. Best I can think of is somehow
    >using thread-specific storage, but you would obviously need to index
    >into it using something OTHER than the PID. Which basically leaves you
    >with the stack. So, unless you could cache the PID in a local
    >> Would gettid() be any better?
    >If you aren't using CLONE_THREAD, gettid() will just return the PID.
    >And if you were using CLONE_THREAD, then getpid() would be worthless for
    >you and you would have to use gettid(). Either way, though, they
    >basically do the same thing (return current->tid vs. current->pid).
    > Robert Love
    >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    >the body of a message to
    >More majordomo info at
    >Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:3.943 / U:0.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site