That last bit cam unclear I admit... By service object I really
An object with threading model of Both aggregating the FTM is
called apartment-neutral (not to be confused with the Neutral
threading model) or apartment-agnostic. You can access such
object from any apartment in the same process. There are
special rules for using interface pointers from within such objects.
Any interface pointer that you know belongs to another apartment-
agnostic object can be freely accessed from within any apartment.
Any client-supplied interface pointer, and any interface pointer
belongin to an object we can't ascertain is apartment-agnostic
must always be stored in GIT and extracted just before invocation
to ensure proper marshaling for that object. Clients of apartment-
agnostic objects must still marshal their interface pointers as usual.
The FTM ensures the target apartment still receives a direct pointer.
Unlike Apartment- and Free-threaded objects, an apartment-
agnistic object can survive the apartment in which it was originally
created being closed. This is because ther's never a stub being
loaded for the apartment-agnostic object so it may continue
to be called from any apartment in the process. Finally, the big
disadvantage of apartment-agnostic objects is that they are
subject to the limitations of both STA and MTA apartments.
The apartment-agnostic model has very few useful applications,
usually for service objects. You should avoid it as a rule.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"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 ,
Objects are allowed to access directly from different apartments but
not interface pointers .
Am I correct here ?
2)
if the above is Ok then
pCoClass1->m_pObj2->Add(pInter1 ); is legal ?
m_pObj2 object might be created on different apartment( single thread
apartment)
is it ok to access it on a multi thread apartment ?
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?
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 )
Thanks