[M3devel] per thread data?

[Tony Hosking]

I have no problem putting the exception handler stack thread local  
into the activation thread local.

On 18 Mar 2009, at 20:11, Jay wrote:

> I'm not looking at it right now, but doesn't seem rather piggy to  
> have two thread locals and data on the side?
>
>
> I'm guessing the data on the side is needed because we need to be  
> able to enumerate our threads, to suspend them all?
>
>
> I understand that having multiple thread locals optimizes their use,  
> but it seems greedy.
> vs. a small heap allocation that combines them.
>
> 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.
>
>
> Another idea, of course, is to look into "__thread",  
> "__declspec(thread)".
>
> 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).
>
>
> Does "__thread" work well on most non-Windows platforms?
> i.e. even if shared object is loaded with dlopen?
>
>
> I could have sworn I saw code out there that was "adaptive".
> It easily/efficiently checked if it was loaded with LoadLibrary or  
> not.
> If so, it'd TlsGet/SetValue (pthread_get/setspecific).
> If not, it'd use __declspec(thread) (__thread).
> The check was based on if __tlsindex was not zero or somesuch. I  
> couldn't track it down though.
>
>
> 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.
>
>
>  - Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090319/5516468d/attachment-0002.html>