title: Re-issuing COM call on the UI thread
body: <p>I am trying to decipher the paragraph below, taken from a blog post <a href="https://devblogs.microsoft.com/premier-developer/asynchronous-and-multithreaded-programming-within-vs-using-the-joinabletaskfactory/" rel="nofollow noreferrer">here</a> which describes COM history in the context of the development for the Visual Studio IDE:</p>
  <blockquote>
  <p>When everything was C++ native code, COM ensured that almost
  everything happened on the main STA thread (i.e. the UI thread). If
  code running in another apartment (e.g. a background thread) called
  any of these COM components the background thread would block <strong>while
  the call was re-issued on the main thread</strong>. This protected the COM
  component from having to deal with <strong>concurrent execution</strong>, but left it
  open to reentrancy (<strong>being invoked while in an outbound call</strong>). This
  technique worked whether the caller was managed (automatically) or
  native code (via the proxy stub that COM would generate for the
  caller).</p>
  </blockquote>
  <p>The questions I have:</p>
  <p>What is the mechanism by which a call is re-issued on another thread? Can you give an example?</p>
  <p>Is the problem mentioned as ‘concurrent execution’ the same as that of thread safety?</p>
  <p>What is being invoked while on an outbound call?</p>
  <p>Thank you.</p>