[PATCH v2 06/11] mfplat: Initialize COM in work queues.

Nikolay Sivov nsivov at codeweavers.com
Tue Feb 11 05:41:51 CST 2020


On 2/11/20 11:13 AM, Paul Gofman wrote:
> On 2/11/20 01:32, Derek Lesho wrote:
>>   
>> +    CoInitializeEx(NULL, COINIT_MULTITHREADED);
>> +
>>       IRtwqAsyncCallback_Invoke(result->pCallback, item->result);
>>   
>> +    CoUninitialize();
>> +
>>       release_work_item(item);
>>   }
>>   
> Can it happen that the apartment is already initialized as apartment
> threaded earlier? If yes, this can leave the caller with uninitialized
> apartment.
Yes, I think it's a valid concern. There is newer API to essentially pin 
MTA for any time period you want by explicitly incrementing/decrementing 
refcount,
but we don't have it available in wine yet. It seems more fitting in 
this case, because it won't be affected by refcount manipulations user 
code might do.

Anyway, such initialization tests have to run in separate process, once 
per test attempt, to exclude unwanted interaction with earlier tests.

Another case to consider - if user code relies on using STA, how does 
that align with already initialized MTA.

And to add more to that heap, explicit initialization calls like 
MFStartup()/RtwqStartup() could be doing COM initialization too 
potentially, that would be unrelated to async queue execution.

I will add more tests for this.




More information about the wine-devel mailing list