Re: ATL threading problem using client COM interface
"Edward Diener" <firstname.lastname@example.org> wrote in message
Igor Tandetnik wrote:
"Edward Diener" <email@example.com> wrote in
The thread needs to use a client COM interface in order to do its
background processing and that client COM interface is passed to the
thread as its data when the thread is created.
You can't just pass COM interface pointers across threads. You have
to marshal them. See CoMarshalInterThreadInterfaceInStream,
CoGetInterfaceAndReleaseStream. Or IGlobalInterfaceTable, CComGITPtr.
So what you are saying is that in my COM server, when I want to pass a
client interface pointer from the main thread in my STA to my worker
thread, I need to use one of the techniques above ?
Yes. You would also need to initialize COM on your worker thread - it
looks like CWorkerThread doesn't itself do that.
Realize this. The client object you want to call from the worker thread
presumably lives in STA. Which means that it's not thread-safe. You can
marshal its interface pointer to a worker thread, but any call this
thread makes on this pointer is marshalled right back to the object's
native STA thread, executed there, and any results marshalled back. This
is the whole point of STA - to guarantee that COM objects living in it
are only ever called on one thread (which allows them to be
Thus, if you hope to gain any performance improvements by spinning a
worker thread, you will likely be disappointed. All you achive is adding
Do any of the COM
smart pointers ( CComPtr, CComQIPtr, or _com_ptr_t ) provide an easy
way to marshall the underlying interface pointer from one thread on
the server to another ?
Which part of "CComGITPtr" did you find unclear?
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