<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side?<BR>
<BR>
<BR>
I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all?<BR>
<BR>
<BR>
I understand that having multiple thread locals optimizes their use, but it seems greedy.<BR>
vs. a small heap allocation that combines them.<BR>
<BR>
Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset.<BR>
<BR>
<BR>
Another idea, of course, is to look into "__thread", "__declspec(thread)".<BR>
<BR>
On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen).<BR>
<BR>
<BR>
Does "__thread" work well on most non-Windows platforms?<BR>
i.e. even if shared object is loaded with dlopen?<BR>
<BR>
<BR>
I could have sworn I saw code out there that was "adaptive".<BR>
It easily/efficiently checked if it was loaded with LoadLibrary or not.<BR>
If so, it'd TlsGet/SetValue (pthread_get/setspecific).<BR>
If not, it'd use __declspec(thread) (__thread).<BR>
The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though.<BR>
<BR>
<BR>
In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others.<BR>
<BR>
<BR>
- Jay<BR><BR></body>
</html>