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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
