Jeremy, Please take in account that gettid() returns a value that unique for the *running threads* across a system.
I.e. for long running java process gettid() can return a value that was previously assigned to one of dead threads. -Dmitry On 2015-07-22 21:22, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The problem with > pthread_self is that it only makes sense in the context of the running > process. When it is written out to the log (as it is in several places), > there really isn't a way (AFAICT) for the user to map it back to anything > useful. > > As it happens, that value is mostly used to write to the log. The places > where it doesn't do so don't seem to need to use pthread_self for any > particular reason. > > Meanwhile, the SIGQUIT stack dump uses java_thread->osthread()->thread_id() > as the nid. On Linux, that maps back to os::Linux::gettid(), whish is also > what gets exposed in /proc. That makes it much easier to see what threads > might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the output of a > SIGQUIT dump. > > The downside of gettid() is that it is only available on Linux>2.4.11, but > that dates from 2001. If we really still want to support it, we could > check for that. > > Thoughts? > > Jeremy > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.