title: Problems related to showing MessageBox from non-GUI threads
body: <p>I'm working on a heavily data-bound Win.Forms application where I've found some strange behavior. The app has separate I/O threads receiving updates through asynchronous web-requests
  which it then sends to the main/GUI thread for processing and updating of application-wide data-stores (which in turn may be data-bound to various GUI-elements, etc.). The server at the other end of the web-requests requires periodic requests or the session times out.</p>
  
  <p>I've gone through several attempted solutions of dealing with thread-issues etc. and I've observed the following behavior:</p>
  
  <ol>
  <li><p>If I use Control.Invoke for sending updates from I/O-thread(s) to main-thread and this update causes a MessageBox to be shown the main form's message pump stops until the user clicks the ok-button. This also blocks the I/O-thread from continuing eventually leading to timeouts on the server.</p></li>
  <li><p>If I use Control.BeginInvoke for sending updates from I/O-thread(s) to main-thread the main form's message pump does <em>not</em> stop, but if the processing of an update leads to a messagebox being shown, the processing of the rest of that update is halted until the user clicks ok. Since the I/O-threads keep running and the message pump keeps processing messages several BeginInvoke's for updates may be called before the one with the message box is finished. This leads to out-of-sequence updates which is unacceptable.</p></li>
  <li><p>I/O-threads add updates to a blocking queue (very similar to <a href="https://stackoverflow.com/questions/530211/creating-a-blocking-queuet-in-net/530228#530228">Creating a blocking Queue&lt;T&gt; in .NET?</a>). GUI-thread uses a Forms.Timer that periodically applies all updates in the blocking queue. This solution solves both the problem of blocking I/O threads and sequentiality of updates i.e. next update will be never be started until previous is finished. However, there is a small performance cost as well as introducing a latency in showing updates that is unacceptable in the long run. I would like update-processing in the main-thread to be event-driven rather than polling.</p></li>
  </ol>
  
  <p>So to my question. How should I do this to:</p>
  
  <ol>
  <li>avoid blocking the I/O-threads </li>
  <li>guarantee that updates are finished in-sequence</li>
  <li>keep the main message pump running while showing a message box as a result of an update.</li>
  </ol>
  
  <p>Update: See solution below</p>