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

[Nicolas Pitre <nico@fluxnic.net>]

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.

And while at it, we might just deinitialize them as soon as we're done 
with them saving resources (on Unix that might turn up to be a no op 
anyway) which is why I suggested doing this within ll_find_deltas() 
directly.


Nicolas