事件驱动（event-driven）的应用程序，尤其是 GUI 应用，通常都围绕“主循环”的概念构建。“主循环” 接受并分派事件，比如 按键/按钮 的按压，进程间的通信（IPC），鼠标移动，计时器和 文件/套接字 I/O，等等。每当事件发生时，主循环通常会 “回调”（call back） 应用程序。
例如， GLib/Gtk+ GUI 库围绕 GMainContext, GMainLoop 和 GSource 类型构建，其他的库也提供了类似的抽象。许多内核或系统层的程序员在 GUI 程序员发出 "主循环" 的叫声时感到非常滑稽 —— GUI 程序员同样也对内核程序员讲到的 put() 或 get() 之类的东西感到困惑。事实是，主循环在内核层是一个广为人知，但又名字不同的概念：它是对系统基元（OS primitives） select(2), pool(2) 之类东西（Windows 上也有等价的东西）的抽象。
注意到多线程应用可能在不同的线程中运行着不同的主循环，来保证回调发生在正确的线程中 —— 在 GLib 中它被实现为使用 g_main_context_push_thread_default() 函数，该函数在线程局部存储（thread-local storage） 中为当前线程记录主循环。该变量（局部存储）会在开始一个异步操作（比如 g_bus_connection_call 或 g_input_stream_read_async() ）时被读取，来保证之前使用过 g_main_context_push_thread_default() 进行设置的上下文中的主循环的回调函数被调用。
一些主循环，比如 GLib 中的那个，允许创建递归的主循环，它被用于实现 GtkDialog 的 run() 方法 。虽然这样的确阻塞（block）了进行回调的线程，但事件仍在处理中（例如，进程输入事件和重绘动画）。具体而言，这就意味着建立对话框的函数可能会被再次调用（在一个回调中）。因此，使用像是 gtk_dialog_() 的函数时，你需要确保你的函数是可重入的（re-entrant)），或者它们保证在对话框显示时不被调用（这通常由模态对话框 (making the dialog modal) 实现，这样触发显示对话框的 UI 操作就不会成功了）。正是因为存在着这样的陷阱，如果你使用了递归的主循环，务必在文档中注明。
主循环并不是 GUI 中独有的概念 —— 许多守护进程（daemons)）（没有 GUI 的后台进程）也是围绕着这个概念编写的，因为它很好地整合任何来源的事件，不论是基于文件描述符的，还是比如计时器或登录事件的综合事件。实际上，在现代 Linux 上，可观数量的一部分系统层次软件都是在 GLib 基础上搭建的，它们使用了 GLib 的主循环抽象来分派事件 —— 大多数时间，这些守护进程在一个或多个主循环中闲置着，等待着 D-Bus 消息的到来或子进程的终止。
既然我们已经揭示了什么是主循环（或者说，主循环的概念是什么），让我们看看为什么写 C 库时你需要注意它。首先，如果你的库不需要向用户发送事件，你不需要关心主循环。然而，大多数库都没有这么简单 —— 例如，libudev 会在插入或改变硬件时发送事件，NetworkManager 想要告知网络的改变，等等。
如果你的库使用了 GLib，要求库的使用者使用 GLib 的主循环通常而言是合适的（如果应用程序使用了其他的主循环，它要么整合 GLib 的主循环（像 Qt 做的那样），要么在分离的线程中使用它），并在建立回调时使用 g_main_context_push_thread_default() 。这也是许多基于 GObject 的库的工作原理，比如 libpolkit-gobject-1，libnm-glib 或 libgudev 。例如，当对象被创建时，与 GUdevClient::uevent 信号关联的回调会被在默认主循环（thread-default main loop）中被调用。对一个共享资源，比如 总线连接（message bus connection），一个比较好的策略是：当方法被调用时，使回调发生在默认线程的主循环中，因为应用程序或库对共享对象的创建没有绝对的控制。在任何情况下，必须总是对与回调有关的函数的回调上下文进行文档说明。
另一方面，如果你没有使用 GLib，一个提供通知的好方法是： a) 提供文件描述符，并且使其在有事件需要处理时变得可读 b) 提供处理事件的函数（可能的话调用用户注册了的回调函数）。一个好的例子是 libudev 中的 udev_monitor_get_fd() 和 udev_monitor_receive_device() 函数。用这种方法，应用程序（或使用你的库的库）能够轻易地控制由什么进程来处理事件。
如果你的库提供了回调函数，确保它们接受 user_data 参数，这样用户可以轻易地将回调与其他数据或对象联系起来。如果你的回调的作用域是未定义的，同样提供一种方法来在不需要的时候释放 user_data 指针 —— 否则应用会泄露需要在之后释放的数据。例子可以在 g_bus_watch_name() 看到。
- 提供整合主循环的 API
- 确保回调函数接受 user_data 参数（可能的话还带一个释放函数）
让用户知道对函数的调用是否会引发 同步I/O（ synchronous I/O）（也叫做阻塞 I/O）是很重要的。例如，一个带用户界面的应用需要对使用者的输入进行响应，甚至可能要为了达到平滑的动画效果而逐帧（every frame）更新用户界面（例如，60 次每秒）。为了避免应用无响应和动画抖动的情况，应用的 UI 线程不应该调用任何进行 同步I/O 的函数。
注意，即便是从本地磁盘加载一个文件也可能造成相当长时间的阻塞 —— 有时达到 10 秒之长。例如，文件可能不在页缓存中，而且硬盘可能处于断电中 —— 或者文件可能在用户的 home 目录，该目录可能使用了网络文件系统，比如 NFS。其他的包括 IPC 的阻塞 I/O 例子有； D-Bus ，Unix domain sockets 。
如果已知一个操作需要很长时间来完成，如果能够取消的话，那通常是一个不错的选择。例如，GLib 中的 GCancellable 类型。另一个不错的（虽然很容易通过 GCancellable 类型实现）的方法是为可能超时的操作设置时间限制（timeout）。这方面的例子可见于g_dbus_connection_send_message_with_reply() 和 g_dbus_proxy_call() ，后者有一个对象范围（object-wide）的时间限制，这样一来时间只需要设置一次。
一些库同时提供同步和异步版本的函数，前者会阻塞主调线程，而后者不会。通常地，异步I/O 使用工作线程实现（在工作线程进行同步 I/O），但它也能够通过 IPC 与其他进程进行交流，或者甚至通过 TCP/IP。例如，libgio-2.0 的异步文件I/O 就是通过工作线程中的 同步I/O 实现的，这仅仅是因为 Linux （现在？）还没有提供足够的适用于库的 异步I/O 方法（见于：colorful notes about Asynchronous I/O）。有利的一面是，这主要是一个实现细节，如果将来有这样的机制，libgio-2.0 实现可以迁移到非线程的方法。
一般 异步I/O 会引入回调（或至少是其他种类的时间通知），这也就意味着主循环的引入。如果库提供了这样的函数，它应该清楚地说明回调发生的线程所在，和它是否需要应用运行在（某种特定的）主循环上。
如果库是线程安全的，对应用本身而言，在工作线程使用同步版本的函数会更简单一些 —— 如果使用了 GLib，使用 g_io_scheduler_push_job() 便是正确的方法。
在某些情况下，同步I/O 是使用递归主循环实现的（通常使用了函数的异步形式）—— 这是应当避免的，它通常会造成各种各样的问题，因为可重入性的问题，以及在等待同步操作完成时等待处理的事件。像往常一样，将代码执行的操作清晰地写在文档中。
一些库，比如 GLib 中的那些，为包括了GAsyncResult / GSimpleAsyncResult, GAsyncReadyCallback 和 GCancellable 类型的，使用了异步 I/O 的全部函数使用了 consistent pattern —— 这样既方便了程序员，又方便了高级语言的绑定，因为重要的东西，比如生命周期，是这个 pattern 的一部分。（例如，你被保证回调总会发生，即便被取消，超时或出错）