EventLoop

A libevent-backed event loop owning an event_base for async I/O dispatch.

final class EventLoop

Mentioned In

Overview

EventLoop wraps libevent’s event_base — the per-loop data structure that watches file descriptors for readiness using the platform’s most efficient I/O multiplexer (kqueue on Apple platforms, epoll on Linux, with POSIX poll(2) as a fallback). Socket and ServerSocket use an EventLoop to schedule read- and write-ready callbacks and drive them to completion.

Shared vs. owned loops

Most callers use the shared singleton. Create a dedicated loop only when you need isolation — for example, in tests that must not contend with application traffic, or when you want distinct fd-watch sets per subsystem. The singleton is fine for the common “one loop per process” pattern; it’s not a locking construct and does not synchronize concurrent use from multiple tasks.

Lifecycle

The typical flow is:

Acquire a loop (shared or init()).
Register I/O via Socket / ServerSocket methods — each method drives the loop internally via runOnce().
Call run() when you want a long-lived event-dispatch loop in a dedicated task, or rely on per-operation runOnce() for one-shot use.
stop() signals run() to exit at its next dispatch boundary.

Backend selection

The runtime backend is exposed via backendMethod. swift-event asserts at test time that this is "kqueue" on Apple platforms and "epoll" on Linux — see Backend and Platforms for the full backend story and the reasons Windows IOCP, Solaris devpoll/evport, and OpenSSL bufferevents are excluded.

Concurrency

Marked @unchecked Sendable to permit handoff of ownership across task boundaries. The underlying event_base is not thread-safe: swift-event does not invoke evthread_use_pthreads(), so concurrent calls into a single EventLoop from multiple tasks are undefined behavior at the libevent level. The invariant is single-owner-per-scope — hand off, do not share. See Production Considerations “Concurrency Model” for the full honest description.

Topics