Re: errno (was Re: C23 thoughts and opinions - why so conservative?)

On 25/05/2024 02:40, Lawrence D'Oliveiro wrote:

On Fri, 24 May 2024 17:57:35 +0200, David Brown wrote:
 

Why would anyone want a variable that exists for /all/ threads in a
program, but independently per thread?  The only use I can think of is
for errno (which is, IMHO, a horror unto itself) but since that is
defined by the implementation, it does not need to use _Thread_local.

 errno is indeed the example that immediately comes to mind for the use of
this feature. It is supposed to have the semantics of an assignable
variable, so how else would you implement it, if not by some (possibly
implementation-specific or special-case equivalent of) the _Thread_local
mechanism?

The normal way for multi-threaded systems is to implement it as a macro.   It might be, for example :
#define errno __thread_data->_errno
or
#define errno *errno()
That is precisely why it is specified in the C standards as a macro, not an external linkage object with static or thread-local storage duration.   (The use of errno in multi-threading C code long predates C11 and _Thread_local.)

 I am in two minds over whether errno is a hack or not. On the one hand, it
makes more sense for system calls (and library ones, too) to return an
error status directly; on the other hand, sometimes maybe you want to
“accumulate” an error status after a series of calls, and errno is a
convenient way of doing this.

I understand its purpose (and I assume that some people find it useful), but I much prefer a clearer flow of return values where possible - I don't like "hidden" return values.  It is particularly bad, IMHO, when setting errno is optional for many library functions - it means that otherwise "pure" functions, such as many from <math.h>, might have side-effects, but you can't rely on them accumulating an error status. It's a lose-lose situation.

 As for other uses of thread-local, I think most of them have to do with
optimizations, like threading itself. For example, imagine a bunch of
threads all contributing increments to a common counter: instead of
continually blocking on access to that counter, they could each have their
own thread-local counter, which periodically has its current value added
to the global counter and then zeroed.

I fully appreciate that sometimes you want data local to a thread, including to different instances of the same thread function.  But I don't see many situations where you'd want the same object to be available per thread in /all/ threads, as you have with thread_local data.  You want all your counter threads to have their own local "counter" object?  That's fine.  But you don't want all your other threads to have that "counter" object that they never use.  I admit this may be more of a concern for those like myself that work on small-systems embedded systems, but the whole concept feels wrong to me.
The only data that really belongs to /all/ threads is for implementing the threading system, or for making the standard library work in multi-threaded programs (such as errno, handles for standard streams, malloc heaps, and the like).  And all that is part of the implementation, not user code.
(And for those working with OS's that are written as user code, rather than implementation code, _Thread_local is useless - there's no standard way to integrate it with your OS code.)