Re: [PATCH] MSVC: port pthread code to native Windows threads

> On Wed, 4 Nov 2009, Daniel Barkalow wrote:
> 
> > On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> > 
> > > 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> > > >
> > > > 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.

> 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.