await expression suspends indefinitely without GLib.MainContext

Direct Answer

Guaranteed thread context: An await continuation runs on whichever thread is currently iterating the GLib.MainContext that was thread-default at the suspension point. It is not guaranteed to be the caller's original thread, nor the GTK main thread — only the thread that owns the captured context.

GTK assertion interaction: If the captured context belongs to a background thread (or no context is running), the continuation executes off the GTK main thread. Any GTK widget access in that continuation triggers gdk_threads_assert_main_thread() failures or GTK_THREAD_CHECK warnings.

How the Mechanism Works

1. At each await, Vala captures GLib.MainContext.get_thread_default() (the thread-default context).
2. When the async operation completes, the continuation callback is queued via g_main_context_invoke() to that same context.
3. The callback runs when that context's main loop iterates (g_main_context_iteration(), gtk_main(), GLib.MainLoop.run()).
4. If no loop iterates the captured context, the callback stays queued indefinitely — the async method appears to hang.

Common Scenarios That Break Expectations

• Background thread without a main loop: Thread.create() starts a thread; await inside captures that thread's (empty) thread-default context. No loop runs there → continuation never fires.
• Library-installed context: libsoup, gstreamer, or similar may push their own thread-default context. Awaits inside their callbacks capture that context, not the GTK main context.
• Mixing GLib.Idle.add()/Timeout.add() with thread-default context: These schedule in the global default context, not the thread-default context. If they differ, continuations resume in the wrong place.

Verification Steps (Run These First)

// 1. Confirm which context is captured at the await site
assert (GLib.MainContext.get_thread_default() == GLib.MainContext.default());
// If this fails, you've identified the mismatch.

// 2. Prove the main loop is actually iterating
GLib.Idle.add(() => {
    stdout.printf("main loop alive\n");
    return GLib.SOURCE_REMOVE;
});

// 3. Minimal reproducer: does a simple timeout await resume?
async void test() {
    await GLib.Timeout.add(100);
    stdout.printf("resumed\n");
}
// Call test() from your startup path. If "resumed" never prints, the captured context has no running loop.

Fix Patterns

• Start async chains from GTK-owned contexts: Call the first async method from a signal handler, GLib.Idle.add(), GLib.Timeout.add(), or Gtk.Application::activate — all run on the main thread with the main context as thread-default.
• Explicitly push the main context (GLib ≥ 2.68, Vala ≥ 0.56):

  var main_ctx = GLib.MainContext.default();
  main_ctx.push_thread_default();
  try {
      await some_async_operation();
  } finally {
      main_ctx.pop_thread_default();
  }

• For background threads that need awaits: Attach a GLib.MainLoop to the thread and run it, or marshal back to the main context via GLib.Idle.add() before awaiting.

One Diagnostic Detail Needed

Does the problematic await occur inside a callback from a third-party library (libsoup, gstreamer, dbus, etc.) or a manually created Thread? This determines whether the fix is "push main context before call" or "restructure entry point."