os::current_thread_id on Linux

[Jeremy Manson]

That's also true of pthread_self.  From the man page:

      Thread  IDs  are  guaranteed  to  be  unique  only within a process.
A thread ID may be reused after a terminated thread has been
       joined, or a detached thread has terminated.

Jeremy

On Wed, Jul 22, 2015 at 11:52 AM, Dmitry Samersoff <
dmitry.samersoff at oracle.com> wrote:

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