Com Threading / квартира поведение несовместимо с маршаллической фабрикой

Я пытаюсь использовать CoRegisterClassObject, чтобы настроить способ загрузки библиотек DLL, в которых есть объекты com. Я пробую что-то, что решит проблему, с которой я столкнулся, когда тип квартиры потока не соответствовал объекту com. Основная идея заключается в том, что поскольку при создании com-объекта использование coregisterclassobject игнорирует реестр, мне необходимо убедиться, что объекты STA создаются в потоках STA, и то же самое для объектов MTA. Вот пример, который я написал в качестве доказательства концепции, которая не всегда ведет себя так, как я ожидаю.

LPSTREAM factory_stream = NULL; //GLOBAL VARIABLE FOR TEST

DWORD __stdcall FactoryThread(LPVOID param)
{
CoInitialize(NULL);
//CoInitializeEx(NULL, COINIT_MULTITHREADED);

cout << GetCurrentThreadId(); //THREAD_ID_2

CustomClassFactory *factory = new CustomClassFactory();
factory->AddRef();
CoMarshalInterThreadInterfaceInStream(IID_IClassFactory, (IClassFactory*)factory, &factory_stream);
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
factory->Release();
CoUninitialize();
return 0;
}

И вот соответствующая часть моей основной функции.

//CoInitialize(NULL);
CoInitializeEx(NULL, COINIT_MULTITHREADED);

cout << GetCurrentThreadId(); //THREAD_ID_1

HANDLE regThread = CreateThread(NULL, 0, FactoryThread, NULL, 0, NULL);
Sleep(5000); //ensures that the factory is registered

IClassFactory *factory = NULL;
CoGetInterfaceAndReleaseStream(factory_stream, IID_IClassFactory, (void**)&factory);

DWORD regNum = 0;
HRESULT res = CoRegisterClassObject(clsid, factory, CLSCTX_INPROC_SERVER, REGCLS_MULTI_SEPARATE, &regNum);
{
TestComObjLib::ITestComObjPtr ptr;
HRESULT hr = ptr.CreateInstance(__uuidof(TestComObjLib::TestComObjCoClass), NULL);
ptr->OutputOwningThreadId(); //THREAD_ID_3 is just from cout << GetCurrentThreadId()

TestComObjLib::ITestComObjPtr ptr2;
HRESULT hr = ptr2.CreateInstance(__uuidof(TestComObjLib::TestComObjCoClass), NULL);
ptr2->OutputOwningThreadId(); //THREAD_ID_4
}
CoRevokeClassObject(regNum);
CoUninitialize();

Идея заключалась в том, что, поскольку реестр не должен использоваться с CoRegisterClassObject, мне нужно было вручную создавать потоковые объекты квартиры в STA вместо текущего потока MTA, и наоборот. Я заметил, что когда CoRegisterClassObject не используется, CoGetClassObject порождает новый поток и вызывает DllGetClassObject в этом потоке, поэтому я подумал, что фабрику классов нужно просто создать в STA, а затем объекты будут там жить.

Проблема, которую я вижу, заключается в том, что в приведенном выше примере идентификаторы потоков не всегда выглядят так, как я ожидал. Если FactoryThread инициализируется как квартира многопоточная, а основной поток многопоточный, то THREAD_ID_2 == THREAD_ID_3 == THREAD_ID_4! = THREAD_ID_1, как и ожидалось (фабрика создает эти объекты, и они могут жить в потоке фабрики). Если эти модели потоков переключаются, то thread_id_3 == thread_id_4, но они отличаются от thread_id_2 и thread_id_1, даже если в потоке 2 могут быть созданы объекты com.

Это кажется противоречивым и может вызвать нежелательное поведение в ситуациях, когда задействован другой поток. Если я полагаюсь только на реестр и не использую coregisterclassobject, если бы я создал объект с бесплатной резьбой в STA, объект был бы создан в другом потоке, созданном com, который был в MTA, а затем, если бы я создал третий поток, который Также был в STA, создание объекта, который поместил бы его в первый созданный поток MTA, а не в новый (То же самое было бы верно, если бы потоковая модель объекта и типы квартир потоков были изменены на обратные). Однако, если бы я использовал coregisterclassobject для создания своей собственной фабрики, как описано выше, и объект был многопоточным, но поток находился в STA, то каждый новый поток, создавший эти многопоточные объекты, породил бы новый поток MTA, который кажется расточительным и противоречивым с тем, что обычно происходит.