skaller <[EMAIL PROTECTED]> writes: > A really cool (non-Posix) implementation would put TLS globals > on the stack base .. but this does require at least one extra > machine register in languages like C which don't provide > a static display (pointer to parent function). For languages > that do, such as Modula and most FPLs, the display pointer > has to be provided anyhow, so the TLS globals come at > no extra cost.
In a C executable, TLS requires one extra machine register. TLS variables are accessed via offsets from that register. So what's the significant difference between that and your proposal? > There are bound to be performance issues if you have to query > any kind of global data base shared between threads to obtain > data local to the thread. The only exception to this is the data > held in the 'task state', which is typically just the machine > registers and in particular the stack. TLS does not require querying a global data base to get thread local data. The only way I can interpret your comments is that you are assuming that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared library). But stack based thread local storage won't work for dlopen'ed shared libraries at all. I think you need to look at the TLS access code before deciding that it has bad performance. Make sure to look at the code in the executable after the linker has optimized it. Ian
