On Wed, 4 Nov 2009, Nicolas Pitre wrote: > On Wed, 4 Nov 2009, Daniel Barkalow wrote: > > > 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. > > Lazy initialization would probably turn up to be more expensive > (checking a flag on each usage) than unconditionally initializing them > once. Remember that those are used at least once per object meaning a > lot. Meh, checking a flag on the same cache line as the lock you're about to take can't be a big incremental cost, especially if it's actually checking whether some sort of cookie is non-zero before doing something with it. > And I much prefer having runtime initialization for both Unix and > Windows than having separate paths on each platform potentially hiding > different bugs. And given that on Unix you can statically initialize > those, then a runtime initialization is certainly not going to be _that_ > costly. Yeah, definitely best to have them match, whichever way we go. I don't think it matters terribly much either way which we use, so long as its consistent. It'd be nice if the static initializers worked, just because people seem to write code with them, but we could just not do that in the future. -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