On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote: > 2009/11/4 Johannes Sixt <j.sixt@xxxxxxxxxxxxx>: > > > > You are right. But #ifdef THREADED_DELTA_SEARCH is about a "generic" > > property of the code and is already used elsewhere in the file, whereas > > #ifdef WIN32 would be new and is is about platform differences. > > > > Anyway, we would have to see what Junio says about the new function calls, > > because he's usually quite anal when it comes to added code vs. static > > initialization. ;) > > I could do it with wrappers for pthread_mutex_lock and _unlock and > lazy init there plus lazy init cond var in cond_wait and _signal, that > way it could be done without any additional code in the first #ifdef. > But I don't see any simple solution for working around > deinitialization, that's why I'd leave non-static initialization. Let > me put some touchups and resubmit for another round. Is it actually necessary to deinitialize? Since the variables are static and therefore can't leak, and would presumably not need to be reinitialized differently if they were used again, I think they should be able to just stay. If Windows is unhappy about processes still having locks initialized at exit, I suppose we could go through and destroy all our mutexes and conds at cleanup time. Pthreads does have the appropriate functions, and it would be correct to use them, although unnecessary. -Daniel *This .sig left intentionally blank* -- 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