[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