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

Russell Leighton
2004-06-07T00:17:00Z

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