On Sat, Mar 25, 2023 at 5:05 PM Bruno Haible <br...@clisp.org> wrote: > > In ISO C 23, > - the type 'once_flag', > - the macro ONCE_FLAG_INIT, > - the declaration of function 'call_once' > are all available from <stdlib.h>, not only from <threads.h>. > > 1) This makes it clear that often call_once is needed in an application > without also needing mutexes. For this reason, I'm moving the 'call_once' > function definition out of the 'mtx' module, into a module of its own. > > 2) The requirement to have 'once_flag' defined in <stdlib.h> would mean > that Gnulib's stdlib.h replacement would have > - to include <pthread.h> on Unix platforms, and > - to include <windows.h> on native Windows. > > Each of the two includes would cause a lot of trouble to users: > - for <pthread.h>, by having many more cases of header file recursion > (we had that often, and the workarounds were always ad-hoc), > - for <windows.h>, by defining lots of identifiers in the namespace. > > This is not worth the trouble, given that the workaround — include > <threads.h> instead of <stdlib.h> — is in the realm of ISO C and > very simple. I'm therefore not implementing ISO C 23 compatibility > on this point. We can revisit it in 10 years or so; then hopefully > some platforms will have restructured their header files and will > define 'once_flag' in <stdlib.h>.
Be careful of call_once. Several years ago I cut over to C++11's call_once. The problem was, it only worked reliably on 32-bit and 64-bit Intel platforms. It was a disaster on Aarch64, PowerPC and Sparc. I had to back it out. The problems happened back when GCC 6 and 7 were popular. The problem was due to something sideways in glibc. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 If you want a call_once-like initialization then rely on N2660: Dynamic Initialization and Destruction with Concurrency. Jeff