Prev: Marshalling C# Strings to VC++ 6.0‏‏
Next: Visual Studio 2010
From: Martin B. on 13 Apr 2010 05:23
Hi all,

I'm currently trying to make sense of a DCOM interface in an app of
ours. The COM server is run via STA (COINT_APARTMENTTHREADED) and we
were thinking of changing it to MTA (COINT_MULTITHREADED).

The interface exists to control certain aspects of the app from another
program and doesn't do anything with the GUI of the app.
Imagine an interface like this:
library OurFooLib
{
interface IOurFoo : IDispatch
{
HRESULT SetClientName([in] long ClientID, [in] BSTR ClientName);
HRESULT GetOpenProject([in] long ClientID, [out, retval] BSTR *pValue);
HRESULT SaveProjectStatus();
....
}
}

Looking at the code that sets up our DCOM server interface, I have the
following.
1.) The MFC Application Starts. InitInstance is called, etc.
2.) Many worker threads are started.
3.) A dedicated thread is started for the DCOM interface

Our separate DCOM worker thread does the following:
--
AfxOleInit();
AfxEnableControlContainer();
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
....
while(...) {
// Wait for COM calls or for app terminate
MsgWaitForMultipleObjectsEx
...
// Dispatch COM calls in this msg loop
while (PeekMessage(&msg, NULL,0,0, PM_REMOVE)) {
DispatchMessage(&msg);
}
...
// Here comes some code to callback registered clients via our
// dispinterface ...
}
....
CoUninitialize();
--

Now I know that AfxOleInit() will already call CoInitialize().

What I do not quite get is what point this call and the call to
AfxEnableControlContainer() could possibly serve in a worker thread.

A very quick test shows that removing them doesn't seem to affect any
operations.

Can anyone tell me what complications we could expect down the round if
we were to remove the call to AfxOleInit and AfxEnableControlContainer ??

cheers,
Martin
From: Stuart Redmann on 14 Apr 2010 10:42
On 13 Apr., 11:23, "Martin B." <0xCDCDC...(a)gmx.at> wrote:

[snip]

> Looking at the code that sets up our DCOM server interface, I have the
> following.
> 1.) The MFC Application Starts. InitInstance is called, etc.
> 2.) Many worker threads are started.
> 3.) A dedicated thread is started for the DCOM interface
>
> Our separate DCOM worker thread does the following:
> --
> AfxOleInit();
> AfxEnableControlContainer();
> CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
> ...
> while(...) {
>    // Wait for COM calls or for app terminate
>    MsgWaitForMultipleObjectsEx
>    ...
>    // Dispatch COM calls in this msg loop
>    while (PeekMessage(&msg, NULL,0,0, PM_REMOVE)) {
>      DispatchMessage(&msg);
>    }
>    ...
>    // Here comes some code to callback registered clients via our
>    // dispinterface ...}
>
> ...
> CoUninitialize();
> --
>
> Now I know that AfxOleInit() will already call CoInitialize().
>
> What I do not quite get is what point this call and the call to
> AfxEnableControlContainer() could possibly serve in a worker thread.
>
> A very quick test shows that removing them doesn't seem to affect any
> operations.
>
> Can anyone tell me what complications we could expect down the round if
> we were to remove the call to AfxOleInit and AfxEnableControlContainer ??

Well, AfxOleInit seems only to manage stuff like DDE initialization,
which should be done by the GUI thread anyway.
AfxEnableControlContainer is solely related to GUI threads, so you can
dismiss it as well. Since you have already tried that you are probably
(or rather certainly) on the safe side: I cannot think of any
different answers to your question.

Regards,
Stuart
 | 
Pages: 1
Prev: Marshalling C# Strings to VC++ 6.0‏‏
Next: Visual Studio 2010