How to pump message for COM STA threads in C#? -

i have main sta thread calls lot methods on com object , secondary sta thread lot work on same object too. want main thread , secondary thread work in parallel (i.e. expect interlaced output main , secondary). know need pump messages in main thread every , - calling get/translate/dispatchmessage in c++ trick.

but i'm having problem getting same strategy working in c#. @ first used currentthread.join() in main thread give control second thread. didn't work. turned application.doevents() - called in main thread whenever wanted second thread run. result second thread grabs control , won't let go - main thread cannot continue until second thread done.

i read documents application.doevents() process waiting events - while getmessage() retrieves 1 message.

what's correct thing do? there c# equivalent of get/translate/dispatchmessage?

thanks

update: second thread running fast, sending lot com call messages main sta thread. added delays in second thread slow down. 2 threads running in parallel. still know if there c# equivalent of getmessage/translatemessage/dispatchmessage.

your original c++ code violated sta contract. states interface pointer must marshaled 1 thread all calls on object made 1 thread. hard requirement single-threaded com servers, not doing risks typical misery associated make calls multiple threads on code not threadsafe. using 2 sta threads not relieve requirement, object owned thread created it. 2nd thread thread , calls cannot made safely since server doesn't support multi-threading.

you somehow got away in c++ code, hard imagine there wasn't glitch , then. com cannot otherwise enforce sta contract on in-process com servers, on out-of-process servers. violating contract generates rpc_e_wrong_thread in case.

anyhoo, no longer getting away in c# program. clr automatically marshals interface pointer you. calls make on 2nd thread marshaled sta thread owns object. there still interleaving 2nd thread's calls can delivered when first thread goes idle , re-enters message loop. there no workaround this, clr handling of interface pointer strictly rules.

this have plenty of consequences code imagine, largest 1 2nd thread doesn't accomplish of anymore. there no concurrency, calls object strictly serialized. , threadsafe. you'll better off making calls 1 thread won't have dance around considerable risk deadlock. making proper message pumping less critical bonus. if 2nd thread other critical work taking advantage of com support single-threaded code can helpful.