Re: Using getpid() often, another way? [was Re: clone() <-> getpid() bug in 2.6?]

[Russell Leighton <russ@elegant-software.com>]

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:

{
   int32_t
     stackvar;

    /* 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");
        exit(-1);

    }

}

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
>variable..
>
>  
>
>> 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 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/
>
>
>  
>