lkml.org 
[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?]
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.115 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site