[HarfBuzz] [PATCH] Implement threading primitives on Windows; fix compile error and leak

[Bradley Grainger]

> > 0003: This implements the HB threading primitives for MSVC on Windows. The "hb_atomic_int_*" macros are defined to use various interlocked intrinsics supported by the compiler. The "hb_mutex_*" macros are implemented with some new functions that delegate to Initialize/Enter/DeleteCriticalSection. 
> > Note that "#include <Windows.h>" is not allowed in hb-private.hh 
> > because hb-open-type-private.hh (which includes it) redefines "LONG", 
> > "ULONG" and other standard Win32 data types with different meanings. 
> > (This naming conflict is rather unfortunate and makes it a little more 
> > difficult to port the library to Windows.)
>
> I didn't know that Windows.h defines LONG, etc.  That's unfortunate.

For reference, the standard Windows data types are here:
http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx

> I've committed your patch for now, but I'm going to find a better way
> to solve this problem.  For starters, HB_MUTEX_INIT is not supposed
> to call a function, and I'm surprised that it compiles with the MS compiler.

The current code is incorrect because InitializeCriticalSection must be called on a CRITICAL_SECTION for Windows to consider it valid; it's not sufficient to just zero out the fields of the structure.

There's no built-in analogue to G_STATIC_MUTEX_INIT on Windows, but now that I've looked through the glib code a little, I see that it could be written in the same way glib does it (i.e., initialise static mutexes on demand the first time they're used by taking a different global mutex that protects static mutex initialisation).

If static mutexes could be avoided, it could make cross-platform portability easier. (And there might be a minor performance gain from not having to enter a global mutex in order to initialise static mutexes.) 

> I'll figure out a way to include Windows.h without conflicting with our
> hb-open-type.h types and will commit.  Please test afterward.

This still has compilation errors, unfortunately.  hb-ot-layout-common-private.hh includes both hb-ot-layout-private.hh and hb-open-type-private.hh. The former includes hb-object-private.hh, which brings in Windows.h, via hb-font-private.hh. The latter typedefs ULONG directly and conflicts with the former definition.

Bradley