Re: Doubts on mixed threading (FTM -Both ) objects
"buddie84" <buddie84@gmail.com> wrote in message
news:1161031525.775168.68210@h48g2000cwc.googlegroups.com...
Hi ,
Please help me to clarify these doubts
See the classes below
All CoClass here are marked "both" in registry and build with Free
Threded Marshaller support .
and thread safe
CoClass1 :
- non creatable
CoClass2 :
- creatable
-client will create this class
CoClass2 :
- non creatable
- object of this class is exposed as a property of CoClass2
- STL collection which stores Variants of type VT_DISPATCH
class CoClass1:Interface1
{
void Init();
};
// define the Enumerator interface
typedef CComEnumOnSTL< IEnumVARIANT,
&__uuidof(IEnumVARIANT),
VARIANT,
_Copy<VARIANT>,
std::vector< VARIANT > > MyEnumeratorType;
// define the collection interface
typedef ICollectionOnSTLImpl<Interface2,
std::vector< VARIANT >,
VARIANT,
_Copy<VARIANT>,
MyEnumeratorType > MyCollectionType;
class CoClass2 : public IDispatchImpl< MyCollectionType
,&IID_Interface2,,,> //collection of class 1
{
Add(Interface3 *pArg)
{
pArg->QueryInterface(__uuidof(Interface3),(void**)&m_pInter3);
//Add to ATL-STL collection
}
};
class CoClass3
{
CComObject<CoClass2> *m_pObj2;
FinalConstruct()
{
CComObject<CoClass2>:: CreateInstance(&m_pObj2);
}
void SomeFunction()
{
StartMyThread(this);
}
property get_Obj2Collection( Interface2 **arg)
{
m_pObj2->QueryInterface(__uuidof(Interface2),(void**)arg);
}
};
static MyThread(void *p)
{
//MULTI Thread Apartment Begin
HRESULT hRes = CoInitializeEx(NULL, COINIT_MULTITHREADED);
CoClass3 *pCoClass3= (CoClass3*) p;
CComObject<CoClass1> *pObj1=NULL;
CComPtr<Interface1>pInter1=NULL;
CComObject<CoClass1>:: CreateInstance(&Obj1);
Obj1->Init();
Obj1->QueryInterface(__uuidof(Interface1),(void**)&pInter1);
pCoClass1->m_pObj2->Add(pInter1 );
//MULTI Thread Apartment End
::CoUninitialize ();
}
1)
some function in CoClass3 will popup a thread and the context passed is
the object itself .
By doing this the object is entering to a new thread/apartment ,
I don't know what a "thread/apartment" is. I don't think such an animal has
ever been defined in COM. I also don't know how to "popup a thread". Do you
mean a thread is created?
If the thread is created, it must call CoInitialize(Ex) and declare what
apartment it will live in. If it is the same apartment as the parent thread,
then it joins the same apartment and there is no apartment boundary to
cross.
Objects are allowed to access directly from different apartments but
not interface pointers .
Am I correct here ?
Objects don't access other objects, but threads do. A thread can access an
interface pointer belonging to another thread if they are both in the same
MTA. Otherwise a thread should only use an interface pointer that is
properly marshaled across the apartment boundary.
2)
if the above is Ok then
pCoClass1->m_pObj2->Add(pInter1 ); is legal ?
You can certainly do whatever you want with the address of the interface,
just don't dereference. Yes, this is legal. But pInter1->DoSomething() might
not be.
m_pObj2 object might be created on different apartment( single thread
apartment)
is it ok to access it on a multi thread apartment ?
A thread that belongs to the MTA cannot use an interface pointer that was
created by a thread from another apartment. The interface pointer must be
marshaled so that the first thread (in the MTA) receives a pointer to a
proxy.
3)
Obj1->QueryInterface(__uuidof(Interface1),(void**)&pInter1);
pCoClass1->m_pObj2->Add(pInter1 );
storing the interface pointer ( pInter1) to collection ..
what will happen when client access this pointer from a different
apartment?
Maybe nothing right away. But you have broken the laws of COM and likely
your application will blow up down the road.
4)
Even If we keep a valid reference for "pInter1", is that going to be
invalid when we call CoUninitialize at the end ?
(I am sure it will become invalid on a single thread apartment )
All interfaces become invalid after CoUninitialize is called.
Important footnote:
Remove the support for the free-threaded marshaller. It is clear from your
post that you don't know what it's for, so get rid of it. You don't need it
and you are likely to shoot yourself in the foot with it.
HTH
Brian