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

[Behdad Esfahbod]

On 05/03/11 15:56, Bradley Grainger wrote:

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

Note that currently we don't use any static mutex.  The only place we use a
mutex is in blobs, and we explicitly initialize those.


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

In cairo we use a non-thread-safe function to initialize static mutexes.  We
call that function from multiple entry points that would ensure that they are
initialized before every being used.  We also call that function from a
DllMain(), so it wouldn't be a problem for DLLs, just for static builds on
Windows that the initializer function would have thread-safety issues.

Now, since we are using C++ in HarfBuzz, I wonder if we can use constructors
to initialize the static mutexes automatically?


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

I gave it another try.

behdad

> Bradley