Vala async methods and GLib MainContext thread-affinity under concurrent requests

Direct Answer

Vala does not guarantee that an async method resumes on the same thread-default GLib.MainContext that started the call. In practice, continuations are dispatched through GLib main-loop primitives and usually run in the thread that owns and iterates the thread-default context captured for the call. Concurrent requests alone do not move resumption to another thread; the break comes from missing or misused context plumbing.

Confirmed Facts vs. Likely Explanation

Confirmed: Vala async methods compile to callback-driven state machines. The language defines no memory model or thread-affinity contract. The normal mechanism is the thread-default MainContext: if a worker pushes a context and runs its loop, continuations for calls made there are dispatched to that context and execute when its loop iterates.

Likely under load: Latency appears because completions are posted to a shared, busy, or blocked MainContext, so resumption waits behind unrelated events. If a request thread does not push its own context, work falls back to the global default and competes with other sources. Movement to a different thread typically requires explicit g_main_context_invoke, a GTask targeting another context, or a third-party library with its own scheduler or thread pool.

What Controls the Choice

• Whether each request thread pushes and iterates its own MainContext for the entire request.
• Whether the context is popped or its loop stopped while callbacks are outstanding.
• Whether async sources are attached elsewhere or libraries use custom schedulers.
• Explicit use of g_main_context_invoke or GTask with another context or thread.

Steps for This Case

1. Give each request worker its own MainContext and MainLoop.
2. Push that context as thread-default before starting async work, and run its loop on that thread.
3. Start async I/O inside that context.
4. Marshal results back through that context instead of touching shared state directly.

Verification

Confirm the toolchain before assuming version behavior:

valac --version
pkg-config --modversion glib-2.0 gio-2.0

Inspect the generated C for the async call to see which scheduling or context API is used. For a minimal repro, each worker thread should create a MainContext/MainLoop, push it as thread-default, start an async method that yields on a real GIO operation, and record the thread-default context plus a thread id at call start and after resumption. Run with and without push_thread_default and with many concurrent workers; mismatches identify the affinity break. For load-only latency, instrument queue depth and timestamps around the yield and continuation.

One Diagnostic Detail

Confirm whether each request thread pushes and iterates its own MainContext for the entire request. If it does not, fix that before tuning anything else.

Version Sensitivity

Exact behavior depends on the installed Vala compiler and GLib/GIO release. Do not rely on remembered version numbers; verify against your toolchain and generated code.