Tom Lane wrote:
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> All TLS variables *must* be static (or implicitly static
>> through extern, i.e. no 'auto' variables)

>I assume you mean static as in not-auto, rather than static as in
>not-global.  Otherwise we have a problem here.

Yes, you are correct.

>> and their addresses can not be
>> assumed to be constant.

>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. In standard C, the effect of this is to forbid the use of
the address of a thread local variable as an initializer for an object
or pointer. For example, the following code will be flagged as an error
by the C compiler: 
#define Thread  __declspec( thread )
Thread int tls_i;
int *p = &tls_i;        //This will generate an error in C.
<end>

(Note this does not apply to C++)


>> Taking addresses of TLS variables should be considered illegal,

>Sorry, no can accept that restriction.

I thought not.  I believe if TLS variables are detail managed through
the win32 API, some of these problems can be avoided (after all, these
examples are for the Microsoft compiler). 

Merlin



Fri, 26 Sep 2003 08:11:44 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: [HACKERS] Threads vs Processes 
"Merlin Moncure" <merlin.moncure@rcsonline.com> 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.

			regards, tom lane

Fri, 26 Sep 2003 10:43:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Threads vs Processes 
Tom Lane wrote:

>"Merlin Moncure" <merlin.moncure@rcsonline.com> 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



Fri, 26 Sep 2003 17:50:47 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: [HACKERS] Threads vs Processes