Class
ServerSocket
A listening TCP server socket built on a non-blocking file descriptor and an EventLoop.
final class ServerSocket
Mentioned In
Overview
ServerSocket represents a socket that has already been bind(2)-ed to a local address and listen(2)-ed on. It accepts incoming client connections through two ergonomic shapes:
accept() — awaits exactly one incoming connection and returns a connected Socket. Use this when your protocol is request/response and you want explicit control over when to service the next connection.
connections — an AsyncThrowingStream<Socket, Error> that yields each accepted Socket as it arrives, until the stream is cancelled or errors. Use this for server loops like for try await client in server.connections { ... }.
Construct a ServerSocket via listen(port:backlog:loop:) or listen(on:backlog:loop:); direct construction is not part of the public API.
Cancellation
The connections stream does not currently propagate Task cancellation down into the outstanding accept event registration. Cancelling the owning task terminates the for-try-await loop in your code but leaves the libevent callback registered until the next activity or until the ServerSocket is deallocated. Workarounds: call close() explicitly to tear down the listener, or drop the last strong reference so deinit runs. See Production Considerations.
Concurrency
Marked @unchecked Sendable to permit handoff of ownership across task boundaries. Concurrent accept() calls or simultaneous iteration of connections from multiple tasks are undefined behavior — libevent state is not locked, and the stored descriptor is closed unilaterally in deinit. The single-owner-per-scope discipline from Production Considerations applies.
Topics
Instance Properties
Instance Methods