On Wed, 4 Nov 2009, Daniel Barkalow wrote: > 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. This is still a bigger cost than not checking such flag at all. Especially if the check will be false on every call but the first one out of millions. I agree this is not significant, but neither is a runtime initialization vs a static one. > 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. Maybe the static initializer can be turned into a global constructor on Windows? Nicolas -- 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