C / C++ / MFC

26-Mar-08 22:18

Hello everyone,

Two questions about message pump in COM STA.

1. The term "message pump", means message queue? Pushing message into the message queue? Or retrieve message from the message queue?

2. What is the impact if the message pump is not alive in STA? It will block method invocation from other apartment?

thanks in advance,
George

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer26-Mar-08 23:09

26-Mar-08 23:09

I've never know message pump to mean anything other than extracting messages from the queue in an ordinary fashion.

All sorts of things can post messages into the queue, but you only handle then in a controlled fashion.

As for COM. I've never implemented a message queue - just Interfaces with methods, so I can't help you there.

But if I'm right STA stands for *single* threaded apartment. Wouldn't other apartments get their own copy of the com object, so it wouldn't block? If you start doing singleton tricks, then that would be your own problem, and you should only do tricks with your eyes open.

Iain.

Iain Clarke appears because ^CPallini still cares.

George_George26-Mar-08 23:43

26-Mar-08 23:43

Thanks Iain!

Informative reply. I am not doing any tricks, I mean for general implementation for STA, if the message pump is blocked by STA owning thread, invocation from other apartment to the current STA will be block? Right?

regards,
George

Roger Stoltz27-Mar-08 0:51

27-Mar-08 0:51

George_George wrote:
for general implementation for STA, if the message pump is blocked by STA owning thread, invocation from other apartment to the current STA will be block? Right?

Yes.
Calls from other apartments implies that the interface has to be marshalled.
When the call is made the RPC will send(!) a message to the STA thread. If that STA doesn't pump messages the call will block. This can happen even if the STA has a message pump but the thread is already inside a message handler or doing something else instead of pumping messages.

This is the same problem as sending messages from one thread to another instead of posting them. The difference between sending and posting is that posting doesn't wait until the message is handled, which means that you cannot deadlock when posting messages but you certainly can when sending them.
However, the RPC in this aspect send messages since all calls return a HRESULT which means that it has to wait for the result before it returns to the caller.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

George_George27-Mar-08 2:12

27-Mar-08 2:12

Thanks Roger,

You mean marshelling from one apartment will use SendMessage other than PostMesssage? Do you have any documents for that? (I have not learned that before)

regards,
George

Roger Stoltz27-Mar-08 2:38

27-Mar-08 2:38

George_George wrote:
You mean marshelling from one apartment will use SendMessage other than PostMesssage?

I think you misunderstood me a little bit...
It's not setting up the actual marshalling with calls to e.g. ::CoMarshalInterThreadInterfaceInStream() or using the GIT that results in a sent message, it's the function call from the other apartment via the marshalled interface that causes this. The message sending happens behind the scenes of the proxy/stub implementation, unless we're talking about free-threaded apartments and that's way too early to talk about so forget about that for now. Wink | ;)

Concentrate on using the STA and calling servers inside it from other apartments.

As for documents regarding this, I assume you've already found a great place to start in Lim Bio Liong's article[^] since you've posted a comment there.
Other good references are the books that he refers to in the article.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

George_George27-Mar-08 3:20

27-Mar-08 3:20

Thanks Roger!

I have read Lim's article and also the book Inside COM. But they both not mentioned whether a call from other apartment to STA will use SendMessage or PostMessage in stub/proxy.

Since you mentioned it in last post, I am just interested how do you think it will use SendMessage?

(not PostMessage or anything else?)

regards,
George

Roger Stoltz27-Mar-08 22:47

27-Mar-08 22:47

Well, in a technical detail calls between apartments may, or may not, use ::SendMessage(). Whether it's an actual ::SendMessage() or ::PostMessage() call doesn't matter and is irrelevant.
The behaviour from the client point of view is the same; it works as if you've used ::SendMessage().

This is my point:
You asked if the call would block and the answer to that is simply 'yes'.
The RPC runtime will actually use ::PostMessage() to place a COM message in the message queue of the server, BUT the proxy will wait for the answer until the server responds.
This can be read in e.g. "Essential COM" by Don Box, chapter 5. If you have a MSDN Library (2005) installation you will also find this chapter as a book excerpt below "Win32 and COM Development". However, I was unable to find it at MSDN online.
Keep in mind that the server and client may not be located on the same machine which would make it impossible to use communication between the server and the client based on window messages. The network has to be involved.
But even if the network is involved, the same rules apply; the call from the client will block and the server must have a message loop that's not deadlocked.

According to my experience it seems to help programmers starting with COM calls crossing apartment boundaries to think of the call as if the message was sent using ::SendMessage(). The reason to even bring that up is that even a beginner have to know that an apartment exposing interfaces must have a message loop. It also assumes that the programmer is familiar with the problems using ::SendMessage(). If the COM beginner is told from the start that ::PostMessage() is used, chances are that he/she would believe that the call somehow would not block.

Regarding why the call is blocking, the simple reason is that each COM interface call must return a HRESULT and the result is unknown until the call has been serviced. For lengthy operations the server should, and usually would, use a callback interface to inform the client about the progress of the asynchronous operation. But this is asynchronous and non-blocking at a higher level.

If you still have question, please explain what you're trying to do that make you ask these questions.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

George_George27-Mar-08 23:38

27-Mar-08 23:38

Cool Roger,

I understand and agree with all of your points, except the below one, "the server must have a message loop that's not deadlocked.", how message loop prevent server from deadlock?

regards,
George

Roger Stoltz28-Mar-08 0:04

28-Mar-08 0:04

George_George wrote:
how message loop prevent server from deadlock?

Perhaps I didn't put that very clear... Unsure | :~

What I meant was when the message loop has called a message handler, the thread doesn't pump messages unless the message handler provides functionality for that.
The message pump of the server normally pumps other messages than COM messages, which means that the STA thread may be busy when a call is made from a COM client.

Example:
Let's say you have a COM server in the main application thread and you've spawned a worker thread and marshalled an interface to the server into the worker thread.
You send a user defined message from the main thread to the worker thread with ::SendMessage(), which boils down to a call via the marshalled interface. The deadlock is now a reality since the STA where the server lives doesn't pump messages, it's waiting for the ::SendMessage() call to return.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

George_George28-Mar-08 0:29