Re: COM objects waiting on a shared resource
Jason S <jmsachs@gmail.com> wrote:
On Apr 16, 12:48 pm, Jason S <jmsa...@gmail.com> wrote:
(B) Window messages: OK, instead of using MsgWait...() where all my
COM objects would have to implement PeekMessage() loops anyway, I'll
just use a GetMessage() loop and TranslateMessage()/DispatchMessage()
to wait for a special broadcast message that signals that the shared
state has changed. Processes that change this shared state will first
do wm_myspecialmessage = RegisterWindowMessage(myUniqueSharedName) to
get a unique message, then I can call PostMessage(HWND_BROADCAST,
wm_myspecialmessage, wExtraInfo, lExtraInfo) to signal that the
shared state changes. Seems like it will work nicely... in an STA...
but how am I support objects that are created in the MTA? (which
don't use message loops, right?)
Hmm, let me come back to this idea. Is there anything wrong with using
a message loop in an MTA to block until a message has been received?
(& if so, is this as simple as creating a dummy hidden window, one per
object, just like in STA?)
There's no technical problem with this, but it sort of defeats the
purpose of an MTA. You would have to have a dedicated thread spinning
the message pump. Presumably, once it receives the message it was
waiting for, it would do the work. Since there's just one thread doing
the work, and there's no concurrency, you could just as well make it
STA.
--
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