0

I am writing a DLL that is called by a third party application. The DLL is called from an MTA thread and any calls back to the third party application must be done on the same thread. From my application I need to call to an out of process COM server and I would like to call back to the third party application from this COM server using an object passed to the COM server.

e.g.

// Called from third party MTA thread
// apiObject must always be called from same thread that called EntryPoint
void EntryPoint(API apiObject)
{
   IMyComClass myComObj = createComObject();
   myComObj.doStuff(apiObject);
}

Class MyComClass : IMyComClass
{
   public void doStuff(API apiObject)
   {
      apiObject.doSomething();
   }
}

Now, if I could change the thread to STA it would work just fine, but unfortunately this is out of my control.

Is there anything simple I can do to force the call coming back in from the COM server to be on the same thread?

Note that the calling application is not a windows forms or WPF application, its a windowless service.

The only thing I can think of is to create a new worker thread from which I do my calls to the COM server and implement my own event queue and just loop waiting for API calls inside EntryPoint. Then I can put delegates to the API calls onto the event queue from the worker thread ensuring they are all called from the correct thread when processing the queue in EntryPoint.

This seems like a very ugly and complex solution to something that should be quite common... Is there a simple(r) solution?

Adriaan
  • 144
  • 13
  • 1
    As worded, I don't see how this would be "something that should be quite common". You started out with this requirement: "The DLL is called from an MTA thread and any calls back to the third party application must be done on the same thread". It's extremely unusual to be running in an MTA thread, and yet have some requirement that code is called on that thread. The whole point of the MTA is that's the apartment where free-threaded code can run, without worrying about which thread it's on. – Peter Duniho Dec 12 '14 at 04:27
  • `The DLL is called from an MTA thread and any calls back to the third party application must be done on the same thread.` This is physically impossible. Outgoing calls from MTA are blocking: the calling thread is suspended until the call returns. Any callback in the interim must necessarily be handled on a different thread. – Igor Tandetnik Dec 12 '14 at 07:04
  • @Peter I guess you're right, it might not be that common... I was also surprised to see that the 3rd party application is calling my class from a MTA AND has this restriction. The "simple solution" I've been looking for is probably to change the thread to STA. – Adriaan Dec 12 '14 at 10:10
  • @Igor If I change the COM server to be in-process (library application) then the call comes back on the same thread just as I want. Is that because it never crosses the process boundary and thus doesn't block (ie. it just works like a normal .net call?). – Adriaan Dec 12 '14 at 10:15
  • If you make the DLL in-process, then the call is no longer a cross-apartment call, but a direct call. Of course it's executed on the same thread - it's just like calling a regular method of a regular class. This is assuming the DLL itself is configured as free-threaded or both-threaded. – Igor Tandetnik Dec 12 '14 at 14:53

0 Answers0