"Merlin Moncure" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
expression involving such an address is not considered a constant
expression.
Ah. That's probably reasonable. Still a bit of a PITA for us, as there
are various places that do give a static variable an initializer
pointing to another static. But that could be worked around I think.
I thought you were saying that the compiler would forbid taking a TLS
variable's address even at runtime.
Tom,
you wrote you wouldn't like the idea of a struct representing the now global variables for a thread, because this would mean that every module would need to access it, and any change of a module-local variable would affect the complete backend.
This could be worked around:
If that global struct is just a list of pointers to memory blocks, each block representing the opaque local data of a module, this can be avoided. This could be duplicated easily for thread creation, if zwo ints representing mem block size and size to copy for each block is included. Additional pointers for creation and cleanup functions could help for more special initializations.
This would make the thing independent of fancy compiler features and platforms.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
