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

[Russell Leighton]

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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/