Which blocking operations cause an STA thread to pump COM messages?
When a COM object is instantiated on an STA thread, the thread usually has to implement a message pump in order to marshal calls to and fro other threads (see here).
One can either pump messages manually, or rely on the fact that some, but not all, thread-blocking operations will automatically pump COM-related messages while waiting. The documentation often doesn't help in deciding which is which (see this related question).
How can I determine if a thread-blocking operation will pump COM messages on an STA?
Partial lists so far:
Blocking operations which do pump*:
Thread.Join-
WaitHandle.WaitOne/WaitAny/WaitAll(WaitAllcannot be called from an STA thread though) GC.WaitForPendingFinalizers-
Monitor.Enter(and thereforelock) - under some conditions ReaderWriterLock- BlockingCollection
Blocking operations which do not pump:
Thread.Sleep-
Console.ReadKey(read it somewhere)
*Note Noseratio's answer saying that even operations which do pump, do so for a very limited undisclosed set of COM-specific messages.
Solution 1:
BlockingCollection will indeed pump while blocking. I've learnt that while answering the following question, which has some interesting details about STA pumping:
StaTaskScheduler and STA thread message pumping
However, it will pump a very limited undisclosed set of COM-specific messages, same as the other APIs you listed. It won't pump general purpose Win32 messages (a special case is WM_TIMER, which won't be dispatched either). This might be a problem for some STA COM objects which expect a full-featured message loop.
If you like to experiment with this, create your own version of SynchronizationContext, override SynchronizationContext.Wait, call SetWaitNotificationRequired and install your custom synchronization context object on an STA thread. Then set a breakpoint inside Wait and see what APIs will make it get called.
To what extent the standard pumping behavior of WaitOne is actually limited? Below is a typical example causing a deadlock on the UI thread. I use WinForms here, but the same concern applies to WPF:
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
this.Load += (s, e) =>
{
Func<Task> doAsync = async () =>
{
await Task.Delay(2000);
};
var task = doAsync();
var handle = ((IAsyncResult)task).AsyncWaitHandle;
var startTick = Environment.TickCount;
handle.WaitOne(4000);
MessageBox.Show("Lapse: " + (Environment.TickCount - startTick));
};
}
}
The message box will show the time lapse of ~ 4000 ms, although the task takes only 2000 ms to complete.
That happens because the await continuation callback is scheduled via WindowsFormsSynchronizationContext.Post, which uses Control.BeginInvoke, which in turn uses PostMessage, posting a regular Windows message registered with RegisterWindowMessage. This message doesn't get pumped and handle.WaitOne times out.
If we used handle.WaitOne(Timeout.Infinite), we'd have a classic deadlock.
Now let's implement a version of WaitOne with explicit pumping (and call it WaitOneAndPump):
public static bool WaitOneAndPump(
this WaitHandle handle, int millisecondsTimeout)
{
var startTick = Environment.TickCount;
var handles = new[] { handle.SafeWaitHandle.DangerousGetHandle() };
while (true)
{
// wait for the handle or a message
var timeout = (uint)(Timeout.Infinite == millisecondsTimeout ?
Timeout.Infinite :
Math.Max(0, millisecondsTimeout +
startTick - Environment.TickCount));
var result = MsgWaitForMultipleObjectsEx(
1, handles,
timeout,
QS_ALLINPUT,
MWMO_INPUTAVAILABLE);
if (result == WAIT_OBJECT_0)
return true; // handle signalled
else if (result == WAIT_TIMEOUT)
return false; // timed-out
else if (result == WAIT_ABANDONED_0)
throw new AbandonedMutexException(-1, handle);
else if (result != WAIT_OBJECT_0 + 1)
throw new InvalidOperationException();
else
{
// a message is pending
if (timeout == 0)
return false; // timed-out
else
{
// do the pumping
Application.DoEvents();
// no more messages, raise Idle event
Application.RaiseIdle(EventArgs.Empty);
}
}
}
}
And change the original code like this:
var startTick = Environment.TickCount;
handle.WaitOneAndPump(4000);
MessageBox.Show("Lapse: " + (Environment.TickCount - startTick));
The time lapse now will be ~2000 ms, because the await continuation message gets pumped by Application.DoEvents(), the task completes and its handle is signaled.
That said, I'd never recommend using something like WaitOneAndPump for production code (besides for very few specific cases). It's a source of various problems like UI re-entrancy. Those problems are the reason Microsoft has limited the standard pumping behavior to only certain COM-specific messages, vital for COM marshaling.
Solution 2:
How the pumping works is actually disclosed. There are internal calls to the .NET runtime which in turn use CoWaitForMultipleHandles to perform the wait on STA threads. The documentation for that API is pretty lacking, but reading some COM books and the Wine source code could give you some rough ideas.
Internally it calls MsgWaitForMultipleObjectsEx with the QS_SENDMESSAGE | QS_ALLPOSTMESSAGE | QS_PAINT flags. Let's dissect what each one is used for.
QS_PAINT is the most obvious, WM_PAINT messages are processed in the message pump. Thus it is really bad idea to do any locking in paint handlers because it will likely get into re-entrant loop and cause a stack overflow.
QS_SENDMESSAGE is for messages sent from other threads and applications. This is actually one way of how the interprocess communication works. The ugly part is that it is also used for UI messages from Explorer and Task Manager, so it pumps WM_CLOSE message (right-click on a non-responsive application in the taskbar and select Close), tray icon messages and possibly something else (WM_ENDSESSION).
QS_ALLPOSTMESSAGE is for the rest. The messages are actually filtered, so only messages for the hidden apartment window and DDE messages (WM_DDE_FIRST - WM_DDE_LAST) are processed.