[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: os::current_thread_id on Linux
From: Jeremy Manson <jeremymanson () google ! com>
Date: 2015-07-27 18:14:09
Message-ID: CAPYFHW0g7yF_y3Cc-A4iOcZZsN6J8A4sA+WWs9by6G6kaYa36g () mail ! gmail ! com
[Download RAW message or body]
Turns out JDK-6661889 already covered this.
Jeremy
On Mon, Jul 27, 2015 at 11:11 AM, Jeremy Manson <jeremymanson@google.com>
wrote:
> Okay, thanks, David. I'll submit a patch to make one API call the other,
> so that there will be no confusion in the future.
>
> Jeremy
>
> On Thu, Jul 23, 2015 at 5:28 PM, David Holmes <david.holmes@oracle.com>
> wrote:
>
>> On 24/07/2015 4:03 AM, Jeremy Manson wrote:
>>
>>> Quick rundown:
>>>
>>
>> Thanks - sorry I couldn't get to this last night.
>>
>> On Solaris, osthread and current_thread_id are the same (thr_self()).
>>>
>>
>> So both user-thread
>>
>> On Windows, they are the same (GetCurrentThreadId()).
>>>
>>
>> Windows is single-level.
>>
>> On OS X, they are the same (pthread_mach_thread_np(::pthread_self()))
>>>
>>
>> Both "kernel" thread
>>
>> On AIX, current_thread_id is pthread_self, and osthread is thread_self()
>>> On non-OS X BSD, current_thread_id is pthread_self, and osthread is the
>>> syscall.
>>>
>>
>> One user and one kernel.
>>
>> I don't see any code that depends on the particular value of
>>> current_thread_id (for example, assuming that it is the same as
>>> thread_self in a meaningful way on AIX, or that it is pthread_self on
>>> AIX). My guess is that the AIX and non-OS X code are just following the
>>> Linux convention.
>>>
>>
>> Yes - port by copy. :(
>>
>> I'm happy to make current_thread_id consistent with
>>> osthread on all of the platforms, or just on Linux (with the
>>> understanding that I can't really test AIX and OS X easily).
>>>
>>
>> Just make the change on Linux, there's really no consistency here to aim
>> for. :(
>>
>> Thanks,
>> David
>>
>> Jeremy
>>>
>>> On Thu, Jul 23, 2015 at 12:16 AM, David Holmes <david.holmes@oracle.com
>>> <mailto:david.holmes@oracle.com>> wrote:
>>>
>>> On 23/07/2015 4:11 PM, Jeremy Manson wrote:
>>>
>>> Okay. TBH, thinking about it more, it's a little weird for
>>> something
>>> named os::current_thread_id() to be different from
>>> Thread::current()->osThread->thread_id(), or for either of them
>>> to be
>>> different from "what the OS thinks the thread id is", so it
>>> seems like
>>> the Right Thing to Do (in the absence of any platform-specific
>>> issues).
>>>
>>>
>>> When there are two different levels of thread ID it isn't that
>>> simple - especially as, like you say, one can be used to look in
>>> /proc while the other can't. So perhaps better naming is in order.
>>>
>>> Cheers,
>>> David
>>>
>>> Jeremy
>>>
>>> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes
>>> <david.holmes@oracle.com <mailto:david.holmes@oracle.com>
>>> <mailto:david.holmes@oracle.com
>>>
>>> <mailto:david.holmes@oracle.com>>> wrote:
>>>
>>> On 23/07/2015 3:15 PM, Jeremy Manson wrote:
>>>
>>> Hey David,
>>>
>>> Thanks for the offer of sponsorship. My goal here is
>>> really to
>>> make the
>>> log output on Linux usable. I want to be able to map
>>> the log output
>>> back to an actual thread. I don't think it really
>>> matters to
>>> users if
>>> the API consistently means "kernel thread ID" or
>>> "threading API
>>> thread
>>> ID", as long as they can figure out what the output
>>> means.
>>>
>>>
>>> I think consistency is important else developers don't know
>>> what
>>> they should be using where - which is the current situation.
>>>
>>> Since what I am doing (in effect) to accomplish my goal
>>> is to ensure
>>> that the API returns the same value as
>>> osthread()->thread_id()
>>> does for
>>> the current thread, I could just... do precisely that.
>>> os::current_thread_id could just return
>>> osthread()->thread_id()
>>> for the
>>> current thread. I don't have easy access to anything
>>> for testing
>>> other
>>> than Linux, though, so whether it worked (or even
>>> compiled) on
>>> the other
>>> platforms would be a bit of a guess (per the last time
>>> we did
>>> this dance).
>>>
>>>
>>> Defining os::current_thread_id() to be
>>> Thread::current()->osThread()->thread_id() assumes you can
>>> make
>>> those calls in the context in which os::current_thread_id()
>>> is used
>>> - if we crash during thread startup then some of those may
>>> be null
>>> and the id not even set. The current implementation is
>>> independent
>>> of the state of thread within the VM.
>>>
>>> So its okay to return the same thing as
>>> Thread::current()->osThread()->thread_id() but it needs to
>>> be done
>>> directly.
>>>
>>> Again any platform for which this would cause a change in
>>> behaviour
>>> needs to be examined. It may be other platforms have the
>>> same
>>> problem you are trying to fix for linux.
>>>
>>> If I get time later I'll try to check what each platform
>>> does.
>>>
>>> Thanks,
>>> David
>>>
>>> Seem reasonable?
>>>
>>> Jeremy
>>>
>>> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes
>>> <david.holmes@oracle.com
>>> <mailto:david.holmes@oracle.com> <mailto:david.holmes@oracle.com
>>> <mailto:david.holmes@oracle.com>>
>>> <mailto:david.holmes@oracle.com
>>> <mailto:david.holmes@oracle.com>
>>>
>>> <mailto:david.holmes@oracle.com
>>> <mailto:david.holmes@oracle.com>>>> wrote:
>>>
>>> On 23/07/2015 8:01 AM, Jeremy Manson wrote:
>>>
>>> Based on the feedback, this seems to be a good
>>> idea,
>>> approximately.
>>> Coleen would have sponsored, but she's going
>>> on vacation.
>>> Anyone else
>>> feel like sponsoring?
>>>
>>>
>>> Hold up a minute! :) There are different notions
>>> of "native
>>> thread
>>> id" that exist. First we have the "user level
>>> thread id" -
>>> this is
>>> what is reported by pthread_self in POSIX and
>>> thr_self in
>>> UI. Then
>>> we also have the OS specific "thread" id, also
>>> referred to
>>> as a LWP
>>> or "kernel scheduling entity" or "kernel thread" -
>>> the id
>>> for this
>>> is what gettid() maps back to on Linux. This
>>> distinction
>>> may not
>>> exist on all platforms.
>>>
>>> Unfortunately os::current_thread_id does not
>>> define which
>>> of these
>>> it represents:
>>>
>>> // thread id on Linux/64bit is 64bit, on Windows
>>> and
>>> Solaris, it's
>>> 32bit
>>> static intx current_thread_id();
>>>
>>> and so on some platforms it returns the "user
>>> thread id" (eg
>>> pthread_self()), and on some it returns the same
>>> as gettid
>>> (ie OSX -
>>> but I don't know if the mach thread id is truly a
>>> "LWP" id ?).
>>>
>>> Also note that on some platforms the osThread
>>> stores the id
>>> of the
>>> "user-level thread" and on some the "kernel
>>> thread". Hence
>>> another
>>> source of confusion. :(
>>>
>>> So if you want to enforce that
>>> os::current_thread_id()
>>> represents
>>> the "kernel thread" then that should be applied
>>> consistently across
>>> all platforms**, and for platforms for which there
>>> is a
>>> change to
>>> make you have to ensure the usage of
>>> os::current_thread_id() is not
>>> semantically altered by the change.
>>>
>>> ** Of course a platform may only have a single
>>> notion of
>>> "thread"
>>>
>>> I'm happy to sponsor such a proposal. And don't
>>> worry about
>>> maintaining compatibility with archaic Linux
>>> versions for
>>> JDK9 (less
>>> cleanup to do later).
>>>
>>> Thanks,
>>> David
>>>
>>> Jeremy
>>>
>>> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson
>>> <jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>>
>>> <mailto:jeremymanson@google.com <mailto:jeremymanson@google.com>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>>>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>>
>>>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>
>>> <mailto:jeremymanson@google.com
>>> <mailto:jeremymanson@google.com>>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>
[Attachment #3 (text/html)]
<div dir="ltr">Turns out JDK-6661889 already covered \
this.<br><br>Jeremy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On \
Mon, Jul 27, 2015 at 11:11 AM, Jeremy Manson <span dir="ltr"><<a \
href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Okay, thanks, David. I'll submit a patch \
to make one API call the other, so that there will be no confusion in the \
future.<div><br></div><div><div>Jeremy</div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 23, \
2015 at 5:28 PM, David Holmes <span dir="ltr"><<a \
href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>></span> \
wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">On 24/07/2015 \
4:03 AM, Jeremy Manson wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Quick rundown:<br>
</blockquote>
<br>
Thanks - sorry I couldn't get to this last night.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Solaris, osthread and current_thread_id are the same \
(thr_self()).<br> </blockquote>
<br></span>
So both user-thread<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Windows, they are the same (GetCurrentThreadId()).<br>
</blockquote>
<br></span>
Windows is single-level.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On OS X, they are the same \
(pthread_mach_thread_np(::pthread_self()))<br> </blockquote>
<br></span>
Both "kernel" thread<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On AIX, current_thread_id is pthread_self, and osthread is \
thread_self()<br> On non-OS X BSD, current_thread_id is pthread_self, and osthread is \
the<br> syscall.<br>
</blockquote>
<br></span>
One user and one kernel.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I don't see any code that depends on the particular \
value of<br> current_thread_id (for example, assuming that it is the same as<br>
thread_self in a meaningful way on AIX, or that it is pthread_self on<br>
AIX). My guess is that the AIX and non-OS X code are just following the<br>
Linux convention.<br>
</blockquote>
<br></span>
Yes - port by copy. :(<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I'm happy to make current_thread_id consistent with<br>
osthread on all of the platforms, or just on Linux (with the<br>
understanding that I can't really test AIX and OS X easily).<br>
</blockquote>
<br></span>
Just make the change on Linux, there's really no consistency here to aim for. \
:(<br> <br>
Thanks,<br>
David<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><span> Jeremy<span class=""><br>
<br>
On Thu, Jul 23, 2015 at 12:16 AM, David Holmes <<a \
href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><br></span></span><span><span class=""> \
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>>> wrote:<br> <br>
On 23/07/2015 4:11 PM, Jeremy Manson wrote:<br>
<br>
Okay. TBH, thinking about it more, it's a little weird for<br>
something<br>
named os::current_thread_id() to be different from<br>
Thread::current()->osThread->thread_id(), or for either of them<br>
to be<br>
different from "what the OS thinks the thread id is", so it<br>
seems like<br>
the Right Thing to Do (in the absence of any platform-specific<br>
issues).<br>
<br>
<br>
When there are two different levels of thread ID it isn't that<br>
simple - especially as, like you say, one can be used to look in<br>
/proc while the other can't. So perhaps better naming is in order.<br>
<br>
Cheers,<br>
David<br>
<br>
Jeremy<br>
<br>
On Wed, Jul 22, 2015 at 10:57 PM, David Holmes<br></span><span class="">
<<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a> <mailto:<a \
href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>><br></span></span><div><div>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><div><div class="h5"><br>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>>>> wrote:<br> <br>
On 23/07/2015 3:15 PM, Jeremy Manson wrote:<br>
<br>
Hey David,<br>
<br>
Thanks for the offer of sponsorship. My goal here is<br>
really to<br>
make the<br>
log output on Linux usable. I want to be able to map<br>
the log output<br>
back to an actual thread. I don't think it really<br>
matters to<br>
users if<br>
the API consistently means "kernel thread ID" or<br>
"threading API<br>
thread<br>
ID", as long as they can figure out what the output means.<br>
<br>
<br>
I think consistency is important else developers don't know<br>
what<br>
they should be using where - which is the current situation.<br>
<br>
Since what I am doing (in effect) to accomplish my goal<br>
is to ensure<br>
that the API returns the same value as<br>
osthread()->thread_id()<br>
does for<br>
the current thread, I could just... do precisely that.<br>
os::current_thread_id could just return<br>
osthread()->thread_id()<br>
for the<br>
current thread. I don't have easy access to anything<br>
for testing<br>
other<br>
than Linux, though, so whether it worked (or even<br>
compiled) on<br>
the other<br>
platforms would be a bit of a guess (per the last time<br>
we did<br>
this dance).<br>
<br>
<br>
Defining os::current_thread_id() to be<br>
Thread::current()->osThread()->thread_id() assumes you can \
make<br>
those calls in the context in which os::current_thread_id()<br>
is used<br>
- if we crash during thread startup then some of those may<br>
be null<br>
and the id not even set. The current implementation is<br>
independent<br>
of the state of thread within the VM.<br>
<br>
So its okay to return the same thing as<br>
Thread::current()->osThread()->thread_id() but it needs to<br>
be done<br>
directly.<br>
<br>
Again any platform for which this would cause a change in<br>
behaviour<br>
needs to be examined. It may be other platforms have the same<br>
problem you are trying to fix for linux.<br>
<br>
If I get time later I'll try to check what each platform does.<br>
<br>
Thanks,<br>
David<br>
<br>
Seem reasonable?<br>
<br>
Jeremy<br>
<br>
On Wed, Jul 22, 2015 at 7:08 PM, David Holmes<br></div></div><span \
class="">
<<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><br> <mailto:<a \
href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>> \
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><br>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>>><br>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><br>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>><br> <br>
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a><br></span><div><div \
class="h5">
<mailto:<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>>>>> wrote:<br> <br>
On 23/07/2015 8:01 AM, Jeremy Manson wrote:<br>
<br>
Based on the feedback, this seems to be a good<br>
idea,<br>
approximately.<br>
Coleen would have sponsored, but she's going<br>
on vacation.<br>
Anyone else<br>
feel like sponsoring?<br>
<br>
<br>
Hold up a minute! :) There are different notions<br>
of "native<br>
thread<br>
id" that exist. First we have the "user level<br>
thread id" -<br>
this is<br>
what is reported by pthread_self in POSIX and<br>
thr_self in<br>
UI. Then<br>
we also have the OS specific "thread" id, also<br>
referred to<br>
as a LWP<br>
or "kernel scheduling entity" or "kernel \
thread" -<br> the id<br>
for this<br>
is what gettid() maps back to on Linux. This<br>
distinction<br>
may not<br>
exist on all platforms.<br>
<br>
Unfortunately os::current_thread_id does not<br>
define which<br>
of these<br>
it represents:<br>
<br>
// thread id on Linux/64bit is 64bit, on Windows and<br>
Solaris, it's<br>
32bit<br>
static intx current_thread_id();<br>
<br>
and so on some platforms it returns the "user<br>
thread id" (eg<br>
pthread_self()), and on some it returns the same<br>
as gettid<br>
(ie OSX -<br>
but I don't know if the mach thread id is truly a<br>
"LWP" id ?).<br>
<br>
Also note that on some platforms the osThread<br>
stores the id<br>
of the<br>
"user-level thread" and on some the "kernel<br>
thread". Hence<br>
another<br>
source of confusion. :(<br>
<br>
So if you want to enforce that os::current_thread_id()<br>
represents<br>
the "kernel thread" then that should be applied<br>
consistently across<br>
all platforms**, and for platforms for which there<br>
is a<br>
change to<br>
make you have to ensure the usage of<br>
os::current_thread_id() is not<br>
semantically altered by the change.<br>
<br>
** Of course a platform may only have a single<br>
notion of<br>
"thread"<br>
<br>
I'm happy to sponsor such a proposal. And don't<br>
worry about<br>
maintaining compatibility with archaic Linux<br>
versions for<br>
JDK9 (less<br>
cleanup to do later).<br>
<br>
Thanks,<br>
David<br>
<br>
Jeremy<br>
<br>
On Wed, Jul 22, 2015 at 11:22 AM, Jeremy \
Manson<br></div></div><span class="">
<<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>>><br> <mailto:<a \
href="mailto:jeremymanson@google.com" target="_blank">jeremymanson@google.com</a> \
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>>>><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>>><br> <br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>><br>
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a><br></span><div><div \
class="h5">
<mailto:<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>>>>>> wrote:<br> <br>
Hey folks,<br>
<br>
os::current_thread_id on Linux now maps to<br>
pthread_self. The<br>
problem with pthread_self is that it only<br>
makes<br>
sense in<br>
the context<br>
of the running process. When it is<br>
written out to<br>
the log<br>
(as it is<br>
in several places), there really isn't a way<br>
(AFAICT) for<br>
the user<br>
to map it back to anything useful.<br>
<br>
As it happens, that value is mostly used<br>
to write<br>
to the<br>
log. The<br>
places where it doesn't do so don't seem<br>
to need<br>
to use<br>
pthread_self<br>
for any particular reason.<br>
<br>
Meanwhile, the SIGQUIT stack dump<br>
uses java_thread->osthread()->thread_id()<br>
as the<br>
nid. On<br>
Linux,<br>
that maps back to os::Linux::gettid(),<br>
whish is<br>
also what gets<br>
exposed in /proc. That makes it much<br>
easier to<br>
see what<br>
threads<br>
might be doing the log write.<br>
<br>
Would it be okay to change<br>
os::current_thread_id<br>
to point<br>
to os::Linux::gettid()? That way, it can be<br>
mapped back to the<br>
output of a SIGQUIT dump.<br>
<br>
The downside of gettid() is that it is only<br>
available on<br>
Linux>2.4.11, but that dates from 2001.<br>
If we<br>
really still<br>
want to<br>
support it, we could check for that.<br>
<br>
Thoughts?<br>
<br>
Jeremy<br>
<br>
<br>
<br>
<br>
<br>
</div></div></div></div></blockquote>
</blockquote></div><br></div>
</blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic