Re: threads/marshalling/callbacks
Jason S <jmsachs@gmail.com> wrote:
Let's say I want to do a simple Advise/Unadvise callback: (I hope I
have this right)
interface ICallbackSink
{
HRESULT Notify([in]DWORD some_data);
}
interface ICallback
{
HRESULT Advise([in]ICallbackSink *psink, [out,retval]DWORD
*pdwCookie);
HRESULT Unadvise([in]DWORD dwCookie);
}
ICallback *pCallback lives in Server S.
ICallbackSink *pCallbackSink lives in Application A.
Both objects are STA.
Application A, in thread A1, calls pCallback->Advise(pCallbackSink,
&dwCookie); and it stores the cookie. In the call to Advise, the
callback calls psink->AddRef() and stores psink in a map<DWORD,
CAdapt<CComPtr<ICallbackSink> >.
Later when pCallback is doing something else, it runs into some event
and calls psink->Notify(some_data); when Application A wants to exit,
it will call pCallback->Unadvise(dwCookie).
My questions:
1) in the call psink->Notify(), does COM somehow know to use thread A1
within Application A's message loop?
COM will use the STA thread that created pCallbackSink object in the
first place. It could be A1, or it could be some other thread (in the
latter case, the pointer has presumably been marshalled to A1).
Note also that message loops belong to threads, not to processes, so
"Aplication A's message loop" is meaningless. A process can have two or
more threads each spinning a message loop, and possibly still more
threads that don't.
or does it use another thread A2?
if it is another thread A2, is it within the same apartment as A1
STA stands for single-threaded apartment. Two threads can't possibly
belong to the same single-threaded apartment: that's why it's called
"single-threaded".
or
does a marshaling step have to occur...
Marshalling definitely occurs to transfer pCallbackSink pointer to the
server (since the sever is a separate process and thus, necessarily, a
different apartment). Whether or not A1 has an original pointer or a
marshalled proxy depends on where and how pCallbackSink was originally
created.
in which case I can't assume
in my sink's Notify() method that I have legitimate access to COM
objects in the apartment used in thread A1?
No you can't, if A1 and the thread that created pCallbackSink are two
different threads. It is completely irrelevant which thread has called
Advise. What's relevant is which thread has created the object: the
object lives in the STA apartment initialized on that thread.
2) Let's say the event that triggers the callback is some other method
call to another interface of the callback object, let's call it
ICauseCallback::Trigger(). Application B calls pCauseCallback-
Trigger(). If I want the callback to be synchronous, Trigger() then
calls a method which calls the appropriate ICallbackSink::Notify()
within the Trigger() function, and Trigger() doesn't return until all
the Notify() calls are complete. What if I want it to be asynchronous?
is there a COM equivalent to PostMessage?
The server can use PostMessage to post a user-defined message to itself,
then immediately return from Trigger(). In that message's handler, it
would then call Notify on the sinks.
As of Win2K, there is such a thing as an asynchronous COM call: see
ICallFactory et al. In this particular case though, this mechanism would
only create unnecessary complications.
Or should my callback sink's
Notify() function be quick and do a PostMessage() if I have lengthy
things to do? (that sounds like it's the case.)
It doesn't have to, but it may of course choose to do so.
3) Let's say the event that triggers the callback is initiated from a
worker thread within the callback server that gets a timer interrupt
or an ethernet packet or something, and it's time to notify the
callback sinks. Does this mean that if I want to do this (call the
sink's Notify() method) that I either have to have the callback and
callback sink's object live in a MTA, or I have to do inter-thread
marshalling for the worker thread to get access to the sink and any
other COM objects?
Which apartment the sink lives in is largely irrelevant: since it's
created in a different process, the server gets the proxy to it anyway.
What's important is which apartment this proxy is valid in, and that's
the apartment where ICallback object lives (because that's the apartment
where Advise call is executed). So, either the worker thread needs to be
in the same apartment as ICallback (this apartment is then necessarily
MTA), or you will have to marshal the pointer from the apartment where
ICallback lives to the apartment where worker lives. Alternatively, the
worker thread can notify ICallback's thread by some non-COM means that
the notifications need be sent (e.g. by sending or posting a window
message to a window created on that thread), and ICallback's thread will
then do the actual work of calling Notify().
4) All this stuff seems to be a headache, and I'm wondering if it
would just be simpler to implement a callback as a marshal-by-value
object
Have you ever implemented an MBV object? If you don't understand
apartments and marshalling, with all due respect, you have no chance to
get it right. And implementing an MBV is a headache in itself.
with a handle to a Win32 Event that can be signaled/waited
upon, and some facilities for windows messages, e.g: (this obviously
would not work with DCOM)
You only think this is easier because you are already familiar with
Win32 events and window messages, but you are not familiar with COM
apartments. Rather than reinventing COM marshalling (which is precisely
what you are describing), I suggest you take the time to educate
yourself.
--
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