This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Destructor support for C++11 thread_local variables


On 10/11/2012 06:58 PM, Roland McGrath wrote:
Is there any order requirement?  And is there a specific rationale for it
other than the aforementioned "principle of least astonishment"?

The rule was basically copied from the rule for variables with static storage duration.


"It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first odr-use (3.2) of any function or variable defined in the same translation unit as the variable to be initialized."

and

"It is implementation-defined whether the dynamic initialization of a non-local variable with thread storage duration is done before the first statement of the initial function of the thread. If the initialization is deferred to some point in time after the first statement of the initial function of the thread, it shall occur
before the first odr-use (3.2) of any variable with thread storage duration defined in the same translation unit as the variable to be initialized."


I believe the rule for statics was there so that code in the TU that relies on side-effects of the initializations will work.

On 10/12/2012 02:15 AM, Jakub Jelinek wrote:
Though, I still wonder how is that implementable.

The way I implemented it? :)


Because a TU could have
say 3 thread_local vars with ctors/dtors, and the middle one of them could
call in the constructor some function that accesses thread_local with
ctors/dtors of some other TU, then you have just partially initialized the
current TU and need to initialize another TU

Yes, and then we come back and finish initializing the first TU when that one is done.


(and it is unclear in what
order they need to be destructed).

Each variable has its own cleanup which is queued when its initialization is complete, just like variables with static storage duration.


Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]