On Fri, Apr 01, 2011 at 11:33:35AM -0700, Greg Clayton wrote: > A "lldb::tid_t" is a thread ID, not a thread opaque pointer. The > "lldb::thread_t" is the already the correct type for the host system's > "thread opaque pointer", but that isn't what this function is trying > to return. > > Dooes linux or BSD have the notion of a thread ID for the current > thread that isn't just a pthread_t?
Linux has gettid(2), so yes. > This function is used mostly for logging when you want to log the > current process ID and the current thread ID. Just some thoughts: Platforms that use user-space thread library implementations can provide some Host code that maps pthread_t pointers (or whatever) via a hash to useful 32-bit numeric id's. We could do that in Host::ThreadCreate for example. It really then becomes an issue for the Host to figure out how to make those ID's useful from a logging/user perspective. But without a good way to map/log those ID's, doing a simple truncation on a pointer is probably just fine *most* of the time since those last bits are going to be the unique ones anyway. So even though the lldb::tid_t(pthread_self()) is "wrong", it still does what it needs to do in this case; give a per-thread-unique integer identifier. So I think the main question is: does having the full 64 bit pointer as an ID give useful info to the developers using user-space threads? I mean, is there some tool (top, ps, etc) or function that one can use to map those values into something meaningful, or is uniqueness the only thing that matters? -- steve _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
