C++ Logo


Advanced search

Re: [wg14/wg21 liaison] On _Thread_local for better C++ interoperability with C (P2478)

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Fri, 11 Feb 2022 20:20:19 +0000
Am Freitag, den 11.02.2022, 20:45 +0100 schrieb Corentin via Liaison:

> Another idea, brought up by Tom, was the idea of some syntax at point of
> use:
> extern "C" thread_local S foo;
> But the compiler still needs to create code for initialization and
> destruction. I guess in that case, the compiler can eagerly run the
> initialization, and that solves the not-yet-initialized problem C faces.

Initialization for each thread?

I think the most intuitive behavior is if

extern "C" thread_local S foo;

behaves just like _Thread_local would do in C and a C++ type
that requires non-trivial initialization would simply not
be allowed, i.e. it behaves like _Thread_local in clang
in c++ mode.

But I might not fully understand the issues here.


> So Tom's solution is actually workable, and mine was just nonsense :)
> But I think there is something else to think about here
> void f() {
> static thread_local S foo;
> c_function(&foo); //#1
> }
> My understanding is that #1 is the issue here. Do we agree with that?
> If that is the case, then I think we might have perfect information here
> Indeed, c_function here is an extern "C" function (Are there cases where it
> isn't?).
> A compiler could diagnose a call to c_function with a non-trivial
> thread_local object before initialization. I think. Has that been
> considered?
> I understand this shifts the burden as a matter of QOI, unless we want to
> mandate it,
> but it avoids burdening both languages and users with extra syntax
> complexity.
> I might miss some important bits of informations so please do not take this
> as more than an unfiltered stream of consciousness
> I think the proposal of no_destroy is generally useful yet orthogonal to C
> compat concerns.
> Thanks,
> Corentin
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/02/0969.php

Received on 2022-02-11 20:20:23