Re: C23 thoughts and opinions - why so conservative?

On 24/05/2024 18:16, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 23/05/2024 23:34, Michael S wrote:

On Thu, 23 May 2024 22:10:22 +0200
David Brown <david.brown@hesbynett.no> wrote:

 

_Thread_local is a special-purpose thing, probably not applicable at
all for programming of small embedded systems, which nowadays is the
only type of programming in C that I do for money rather than as hobby.

>
I have never seen the point of it either.  Why would anyone want a
variable that exists for /all/ threads in a program, but independently
per thread?

 Very common in kernel programming (e.g. the use of '%gs' in x86_linux)
as a pointer to the 'per-cpu' data structure.
 We use thread local  to implement 'self' methods in certain
classes (so rather than passing pointers around, one can
simply call class::self() to get a pointer to the
class for each thread.
 class c_processor {
  ...
     /**
      * Per-thread value of the processor object.
      */
     static __thread c_processor *p_this;
  ...
 public:
     c_processor(c_system *, c_logger *, processor_number_t, bool);
     ~c_processor(void);
          static c_processor *self(void) { return p_this; }
 ...
        c_processor *pp = c_processor::self().

I can see that.  But you only want a few of these, and it is typically in very low-level code that is full of compiler-specific or target-specific stuff anyway.  Such things could be compiler extensions or other implementation-specific features.
After all, "thread_local" is useless for the vast majority of OS's (counting numbering of OS's, not number of users).  You can't use it unless the C (or in this case, C++) implementation has support for the OS in the library and compiler.