Re: MTA, STA show no change in concurency
You can create one thread that enters STA, and have it call
CoRegisterCoClass for one coclass (don't forget to run a message
pump on that thread). You can further create another thread that
enters MTA, and have it call CoRegisterCoClass for another coclass
(that thread can go to sleep right away, but it must not terminate).
Before you ask, there is no support in ATL for such an
unconventional setup, you will have to code it yourself.
Is there any thing wrong in letting every thread/coclass have its own
I'm not sure what you mean by coclasses having a message pump.
An STA thread must run a message pump in order to accept incoming COM
calls. An MTA thread can too, but usually such threads don't create any
windows and don't receive any messages, so GetMessage becomes roughly
equivalent to Sleep. Unless you are doing something unusual, running a
message pump on an MTA thread is pointless.
so one is not dependent on someother coclass to keep the process in
I don't understand this statement at all. Do you believe a process must
run a message pump in order to stay in memory?
In our project those two coclasses may not be of same family, and
logically related, so one coclass may not know that other is closing.
What do you mean by "coclass is closing"?
Because of this, every coclass, onhis own, should make sure that
process is in memory.
Well, the project doesn't magically terminate itself. It terminates when
WinMain exits. Normally, you'd call CAtlExeModuleT::Run, which
terminates five seconds after the last COM object is destroyed. If you
implement an unconventional setup not directly supported by ATL, it's up
to you to make sure WinMain doesn't exit prematurely.
With best wishes,
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925