Howdy, Is there any policy on making static initializers thread-safe? I'm working on an experimental patch to introduce threading, but I'm running into a few non-thread-safe bits like this, in convert.c: static const char *conv_attr_name[] = { "crlf", "ident", "filter", "eol", "text", }; #define NUM_CONV_ATTRS ARRAY_SIZE(conv_attr_name) static void convert_attrs(struct conv_attrs *ca, const char *path) { int i; static struct git_attr_check ccheck[NUM_CONV_ATTRS]; if (!ccheck[0].attr) { for (i = 0; i < NUM_CONV_ATTRS; i++) ccheck[i].attr = git_attr(conv_attr_name[i]); user_convert_tail = &user_convert; git_config(read_convert_config, NULL); } } The easy fix would be to stick the initialization bit into an 'extern int init_convert_config();' function, and invoke it prior to the threaded part of my code. That would be no worse than the current state of affairs, which is to say that adding threading is rife with hidden perils. A more comprehensive fix might be: #include <pthread.h> static pthread_mutex_t convert_config_mutex = PTHREAD_MUTEX_INITIALIZER; static void convert_attrs(struct conv_attrs *ca, const char *path) { int i; static struct git_attr_check ccheck[NUM_CONV_ATTRS]; pthread_mutex_lock(&convert_config_mutex); if (!ccheck[0].attr) { for (i = 0; i < NUM_CONV_ATTRS; i++) ccheck[i].attr = git_attr(conv_attr_name[i]); user_convert_tail = &user_convert; git_config(read_convert_config, NULL); } pthread_mutex_unlock(&convert_config_mutex); } Unfortunately, I don't think mingw/msys supports PTHREAD_MUTEX_INITIALIZER. A possible workaround would be: static pthread_mutex_t convert_config_mutex; static void init_convert_config_mutex() __attribute__((constructor)); static void init_convert_config_mutex() { pthread_mutex_init(&convert_config_mutex); } But then, I'm not whether mingw/msys supports __attribute__(constructor). Can anyone give me some guidance before I go to much further into the weeds (and I'm neck-deep as it is)? Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html