Messages in this thread | | | Date | Sun, 06 Jun 2004 20:20:54 -0400 | From | Russell Leighton <> | Subject | Re: 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:
{ 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/ > > > >
- 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/
| |