I think C++ should simply support

extern "C" thread_local int x;

as an indication that this is a "C" thread_local variable
that does not require dynamic initialization.


C already uses thread_local via the header definition,
I do not see how making it a keyword or not matters
at all.


Martin


Am Montag, den 04.10.2021, 15:33 -0400 schrieb Hubert Tong via Liaison:
> The paper does not change the de jure status quo of this concern; however,
> I will note that it probably changes the situation in practice:
> _Thread_local is more like C++'s constinit thread_local than plain
> thread_local.
>
> I cannot recommend for users of C to adopt using thread_local for mixed
> C/C++ uses because thread_local for C++ is more expensive than
> _Thread_local is in C.
> C++ uses of a thread_local variable from a translation unit that does not
> define said variable must, for deferred-initialization implementations
> (i.e., all implementations I am aware of), assume that the variable may
> have dynamic initialization/finalization.
>
> I should also point out that it is a reality of some existing
> implementations that variables defined _Thread_local in C will fail to link
> when uses in C++ are declared thread_local (without constinit). It is a
> reality with more existing implementations that variables defined
> thread_local in C++ with dynamic initialization/finalization could end up
> uninitialized/unregistered when accessed via _Thread_local declarations in
> C.
>
> This paper exacerbates the confusion between C's _Thread_local and C++'s
> thread_local.
>
> -- HT
> _______________________________________________
> Liaison mailing list
> Liaison_at_lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/10/0858.php