Hi Bradley, Thanks for the patches.
On 04/25/11 13:01, Bradley Grainger wrote: > 0001: This fixes a compile error with MS Visual C++ 2010, Fixed already. > 0002: This adds a "hb_mutex_free" macro that is called by hb_blob_destroy > (to free the mutex object created in "hb_blob_create"). If GLib is available, > this is defined as g_static_mutex_free. > This fixes a bug that leaks GStaticMutex objects; from > http://developer.gnome.org/glib/unstable/glib-Threads.html#g-static-mutex-free: > "if you have a GStaticMutex as a member of a structure and the structure is > freed, you should also free the GStaticMutex." Thanks. Fixed. > 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. 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. 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. Thanks again, behdad > Bradley > > > > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
