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

[Behdad Esfahbod]

On 05/11/11 15:58, Bradley Grainger wrote:
>>> Now, since we are using C++ in HarfBuzz, I wonder if we can use 
>>> constructors to initialize the static mutexes automatically?
>>
>> This little gem seems to do the trick:
>>
>> struct hb_static_mutex_t : hb_mutex_t
>> {
>>   hb_static_mutex_t (void) {
>>     hb_mutex_init (this);
>>   }
>> };
>>
>>
>> What do you think?
> 
> I _think_ this is OK, because critical sections are allowed be initialised in DllMain (according to http://msdn.microsoft.com/en-us/library/ms682583.aspx): "There are serious limits on what you can do in a DLL entry point. ... If your DLL is linked with the C run-time library (CRT), the entry point provided by the CRT calls the constructors and destructors for global and static C++ objects. Therefore, these restrictions for DllMain also apply to constructors and destructors and any code that is called from them" but "For example, DllMain can create synchronization objects such as critical sections and mutexes"

Explicitly doing it from DllMain definitely works, since we do that in Cairo.
 I'm sure the constructor would do just fine.

> It does seem like this would need a destructor, too, to avoid leaking CRITICAL_SECTION objects (unless they're only ever destroyed at process shutdown, when it wouldn't be necessary). Of course, then the struct would need to be made non-copyable to avoid inadvertent early destruction.

Right.  I'll work on that now.  Need to streamline my style re use of
constructor/destructor vs explicit init/finish functions.

Also, re USHORT etc, trying to avoid including mutex stuff and the
hb-open-type.h stuff from the same file is very debilitating.  Can you please
try to see if #define'ing USHORT to HB_USHORT, etc would work?  Lets assume we
always include Windows.h before hb-open-type.h...

Thanks,
behdad


> Bradley
>