How do I create a custom SynchronizationContext so that all continuations can be processed by my own single-threaded event loop?

Say you're writing a custom single threaded GUI library (or anything with an event loop). From my understanding, if I use async/await, or just regular TPL continuations, they will all be scheduled on TaskScheduler.Current (or on SynchronizationContext.Current).

The problem is that the continuation might want to access the single threaded parts of the library, which means it has to execute in the same event loop. For example, given a simple game loop, the events might be processed like this:

// All continuation calls should be put onto this queue
Queue<Event> events;

// The main thread calls the `Update` method continuously on each "frame"
void Update() {
    // All accumulated events are processed in order and the queue is cleared
    foreach (var event : events) Process(event);

    events.Clear();
}

Now given my assumption is correct and TPL uses the SynchronizationContext.Current, any code in the application should be able to do something like this:

async void Foo() {
    someLabel.Text = "Processing";

    await BackgroundTask();

    // This has to execute on the main thread
    someLabel.Text = "Done";
}

Which brings me to the question. How do I implement a custom SynchronizationContext that would allow me to handle continuations on my own thread? Is this even the correct approach?

Implementing a custom SynchronizationContext is not the easiest thing in the world. I have an open-source single-threaded implementation here that you can use as a starting point (or possibly just use in place of your main loop).

By default, AsyncContext.Run takes a single delegate to execute and returns when it is fully complete (since AsyncContext uses a custom SynchronizationContext, it is able to wait for async void methods as well as regular async/sync code).

AsyncContext.Run(async () => await DoSomethingAsync());

If you want more flexibility, you can use the AsyncContext advanced members (these do not show up in IntelliSense but they are there) to keep the context alive until some external signal (like "exit frame"):

using (var context = new AsyncContext())
{
  // Ensure the context doesn't exit until we say so.
  context.SynchronizationContext.OperationStarted();

  // TODO: set up the "exit frame" signal to call `context.SynchronizationContext.OperationCompleted()`
  // (note that from within the context, you can alternatively call `SynchronizationContext.Current.OperationCompleted()`

  // Optional: queue any work you want using `context.Factory`.

  // Run the context; this only returns after all work queued to this context has completed and the "exit frame" signal is triggered.
  context.Execute();
}

AsyncContext's Run and Execute replace the current SynchronizationContext while they are running, but they save the original context and set that as current before returning. This allows them to work nicely in a nested fashion (e.g., "frames").

(I'm assuming by "frame" you mean a kind of WPF-like dispatcher frame).