Module service_server 

The commit service’s loop. What: The resident service’s loop: accept connections, queue requests in arrival order, land what is queued as a batch, answer each client, and exit when told to retire. Why: One writer lands every commit, so there is no lock to take, hold or wait for: order is the order of the queue, the cost of the one durable write is shared by the batch, and a client that waits blocks on its socket instead of polling (doc/planning/cli-git-resident-service.md). The service never starts itself: the operating system hands it the listening socket (socket activation), or a development run binds one.

In TS you’d write (pseudocode):

for await (const batch of queue.batches()) { const outcomes = await landBatch(batch); for (...) reply(outcome); }

Structs

ServeSettings

How a service run behaves apart from where it listens and what it lands.

Enums

Bind

Where the listening socket comes from.

Constants

IDLE_EXIT

How long the service waits with nothing to do before it exits; the manager’s socket stays, so the next connection starts it again. Bazel’s server does the same with --max_idle_secs, whose default is three hours, which is this value’s precedent.

INHERITED_DESCRIPTOR

File descriptor the service manager passes the listening socket on (SD_LISTEN_FDS_START).

MAX_BATCH

The most requests landed as one batch.

REQUEST_READ_TIMEOUT

How long a connection may take to send its request line before it is dropped.

Functions

bind

What: Opens the listening socket. Why: Socket activation hands over a bound socket, which is the normal way; the others serve tests and development runs.

serve

What: Runs the service until it is told to retire. Why: Recovery runs before the first connection is accepted; then the loop takes everything queued as one batch, groups it by branch in order of first arrival, lands each group, and answers.