STA thread. Basically, your thread is not allowed to do
anything else. All actions must come within window handlers.
You seem to be better served by using the MTA. Why do
Ok. I appreciate your help. I'm getting close to understanding this.
What I think I'm trying to say is that you don't need to have a message
pump in your thread but you need to be aware that there is a hidden
window associated with the STA thread that needs to be pumped on
occassion with a call to a function like MsgWaitForSingleObject(). The
literature confuses me a bit. I get confused on whether I need to
PeekMessages etc... or just Pump messages in the hidden window. Here
are two articles
http://www.techvanguards.com/com/concepts/multithreading.asp
Quote(talking about hidden window):
This serialization behavior in the STA is implemented by COM using the
standard Win32 window messaging architecture. What happens is COM
interjects a hidden window between the client and the object in the
STA. Whenever the client calls into an object in the STA, COM
intercepts the call, bundles it into a windows message, and then posts
the message into the message queue of the hidden window. Once the
hidden window gets to the message in its queue, it unbundles the
message and then makes the actual call into the STA object. This is all
made possible because the hidden window runs on the one thread that
lives in the STA. In order for the hidden window to receive and handle
calls/messages, it must continuously check and process its message
queue. This means that the STA thread is required to run a message pump
(a process which checks and handles messages from a message queue) in
order to live.
and
http://blogs.msdn.com/larryosterman/archive/2004/04/28/122240.aspx
Quote(talking about MsgWaitForSingleObject)
When a thread indicates that it's going to be in single threaded
apartment, then the thread indicates to COM that it will host single
threaded COM objects. Part of the contract of being an STA is that the
STA thread cannot block without running a windows message pump (at a
minimum, if they block they must call MsgWaitForSingleObject -
INTERNALLY, COM uses windows messages to do inter-thread marshalling).
Thanks for your help
Igor Tandetnik wrote:
Ron Ayoub <ronaldayoub@yahoo.com> wrote:
My question is basic. Lots of articles say that when CoInitialize() is
called a thread enters an STA and a message loop is created INTERNALLY
in order to serialize calls to the objects created in that STA.
Can you cite one such article? STA apartment _requires_ a message pump,
but does not automatically _provide_ one. It is the responsibility of
the thread entering STA to run a message pump if it wants to accept
incoming cross-apartment calls.
Lots
of articles also say that you have to create and pump message
EXPLICITLY if you expect cross apartment interaction to occur. This
latter one is kind of strange to me since I've done lots of
programming of server applications that don't have any message loop
at all and they enter into an STA at the start and spawn numerous
threads and there is no problem with these numerous threads
interacting with objects created in separate threads.
These applications probably violate COM rules by calling STA objects
from worker threads without proper marshalling. Neither the compiler nor
the runtime will stop you from calling a thread-unsafe object
concurrently from multiple threads. You might even get away with it for
a while, until a race condition bites you at the most unfortunate
moment.
Is it because
all threads are in a single STA.
You do realsize that STA stands for "single-threaded apartment", right?
As in the apartment that can only ever contain one thread?
In that case, the literature that
claims one thread per STA is also wrong or misleading in some manner.
The literature is correct in this regard.
--
With best wishes,
Igor Tandetnik
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