title: Using WPF (which requires STAThread) with an API that can't work with STAThread
body: <p>I am writing a WPF application that has an optional dependency on an API that has a simple requirement; It MUST be initialized/used on a thread that does NOT have the STAThread attribute. Of course, WPF requires STA so that makes everything easy.</p>
  
  <p>In this case, WPF is required no matter what. This third party API is required only when the user chooses to enable this functionality in the application. This means that the WPF application is already running once it is time to invoke the other API.</p>
  
  <p>If you do not decorate your main method with [STAThread], is it automatically an MTA thread? In this case, does that mean I can create a new MTA thread and use the other API on it? </p>
  
  <p>If that would work, then I guess that any events from this API could talk to the WPF app using the Dispatcher (for raising events that need to show in the UI etc.). However, is there a simple way that my WPF app can "invoke" functionality on the MTA thread to make API calls?</p>
  
  <p>In MTA I guess that every thread should be able to play with state, but I guess my STA thread (WPF app) can't just "reach into" the MTA thread and perform API calls?</p>
  
  <p>There is so much possibility for confusion here that I would love some input on how to design something like this!</p>
  
  <p>Thanks!</p>
  
  <p>[Edit July 8th]</p>
  
  <p>Okey, I had some concepts confused in the above. The threading model is of course set for a PROCESS, not for each thread, and this third party API can't work with STA process.</p>
  
  <p>Currently, the only way I see out of this mess is to write a service that communicates with this API, then communicate with this service using named pipes. This is not trivial at all, an ugly ugly workaround, but the third party API is not under my control. Such is life. :|</p>