Understanding the Dispatcher Queue Understanding the Dispatcher Queue wpf wpf

Understanding the Dispatcher Queue


There's very little documentation surrounding the Dispatcher, so you'll have to disassemble around a bit to know about the inner workings.

A dispatcher is basically something which performs work around the application's Message Pump. The one in question sits on top of the windows message loop.

As a consequence, there can only be one application Dispatcher - the global dispatcher object accessible by Application.Current.Dispatcher. Other dispatchers are possible by accessing Dispatcher.CurrentDispatcher, which according to the documentation

Gets the Dispatcher for the thread currently executing and creates a new Dispatcher if one is not already associated with the thread.

However, calling Run on this new dispatcher will be blocking.

When you do a Dispatcher.PushFrame, it pushes an inner execution loop into the Dispatcher - that's the general idea of a frame. Anything that inherits from DispatcherObject such as DispatcherFrame will have its dispatcher set to the current one. We can verify this by looking at its constructor.

private Dispatcher _dispatcher;protected DispatcherObject(){    this._dispatcher = Dispatcher.CurrentDispatcher;}

Of course, having a simple event loop isn't enough - there are times when you need to subvert the current event loop to force other work to be done. And that's why you have a DispatcherFrame. This is what actually constitutes the event loop. When you push a frame into the Dispatcher, this is what happens:

while (frame.Continue)        {            if (!this.GetMessage(ref msg, IntPtr.Zero, 0, 0))            {                break;            }            this.TranslateAndDispatchMessage(ref msg);        }

It is in the TranslateAndDispatchMessage that the prioritized queue in the Dispatcher gets evaluated, after a message is taken out.

If an operation takes a long time to run on the dispatcher, it temporarily stops the event loop, and because it doesn't respond to signalling, the application seems like it stops responding.

Here's an article which uses a frame to force the UI to respond by allowing the event loop to run shortly.

As for accessing the queue, as it is, there is no way to know the state of the queue outside of the Dispatcher. This is an internal detail, and it's reasonable that it's not exposed.