Introduction

GLib and GObject signals are often used in event-driven code, so it is easy to assume they behave like queued asynchronous events. By default, they do not: signal emission is synchronous, and handlers run immediately in the same call chain as the emitter.

Signals Are Synchronous by Default

When you call g_signal_emit, g_signal_emit_by_name, or a generated signal wrapper, GLib invokes the connected handlers before control returns to the caller.

That means this sequence:

1. Emit signal
2. Run handlers
3. Continue after emission call

is all one synchronous flow.

A small C example makes the order obvious:

1#include <glib-object.h>
2#include <stdio.h>
3
4static void on_ping(GObject *self, gpointer user_data) {
5    printf("handler running\n");
6}
7
8int main(void) {
9    GObject *obj = g_object_new(G_TYPE_OBJECT, NULL);
10
11    g_signal_new(
12        "ping",
13        G_TYPE_OBJECT,
14        G_SIGNAL_RUN_LAST,
15        0,
16        NULL,
17        NULL,
18        NULL,
19        G_TYPE_NONE,
20        0
21    );
22
23    g_signal_connect(obj, "ping", G_CALLBACK(on_ping), NULL);
24
25    printf("before emit\n");
26    g_signal_emit_by_name(obj, "ping");
27    printf("after emit\n");
28
29    g_object_unref(obj);
30    return 0;
31}

The output order is:

before emit
handler running
after emit

If signals were inherently asynchronous, the final line could appear before the handler. It does not.

Signal Emission Does Not Create a Background Task

This is the most important misunderstanding to avoid. Emitting a signal does not:

• create a worker thread
• queue work to the main loop automatically
• defer execution until later

It simply calls the handlers according to signal rules and connection order.

So if a signal handler does expensive work, the emitter blocks until that work is done. In a GTK application, that can freeze the UI if the signal was emitted on the main thread.

What Thread Runs the Handler?

The handler runs in the same thread that emitted the signal unless your own code explicitly arranges something else.

That means if a worker thread emits a signal on an object, the connected handlers also run on that worker thread. GLib does not magically bounce those handlers back to the GUI thread.

This matters a lot in GTK-style applications where UI objects must be touched from the main thread. A signal is just a call path, not a thread handoff.

How to Make the Effect Asynchronous

If you want "emit now, handle later on the main loop," you need to schedule that yourself. A common pattern is g_main_context_invoke:

1#include <glib.h>
2
3static gboolean notify_main(gpointer data) {
4    g_print("running later on the main context\n");
5    return G_SOURCE_REMOVE;
6}
7
8void worker_finished(void) {
9    g_main_context_invoke(NULL, notify_main, NULL);
10}

You can also use g_idle_add when you want to schedule work for the next idle iteration of the main loop:

g_idle_add(notify_main, NULL);

These are asynchronous relative to the current call because they queue a source into a GMainContext. That queuing is separate from the signal system itself.

Signals and the Main Loop Are Related but Different

GLib programs often use both signals and the main loop, which is why they are easy to conflate.

• Signals are synchronous notifications between objects.
• The main loop is an event dispatcher that runs sources such as timeouts, I/O watches, and idle callbacks.

You can combine them. For example, a signal handler might schedule follow-up work with g_idle_add, or a timeout callback might emit a signal. But one concept does not automatically imply the other.

When Synchronous Signals Are Useful

The synchronous model is actually valuable because it gives you predictable ordering. The emitter can know that by the time g_signal_emit returns:

• all handlers have run
• any accumulator logic is complete
• return values or stop conditions have already been resolved

That makes signals a good fit for internal object notifications, validation hooks, and coordinated state changes where immediate ordering matters.

Common Pitfalls

• Assuming signals are queued asynchronously just because the application uses a main loop.
• Emitting a signal from a worker thread and then touching GTK UI in the handler.
• Doing long-running work inside a signal handler and blocking the emitter.
• Confusing g_idle_add or g_main_context_invoke behavior with the behavior of signals themselves.
• Using signals as a replacement for real background execution.

Summary

• GLib and GObject signals are synchronous by default.
• Handlers run immediately in the same call chain as the emission.
• A signal does not create a thread or queue work to the main loop automatically.
• If you need asynchronous behavior, schedule it explicitly with mechanisms such as g_idle_add or g_main_context_invoke.
• Understanding that distinction prevents many UI-thread and blocking bugs.