Module limits 

Step limits in server mode.

The limit lives on the server and every permit is a lease: the worker holding it renews it while its step runs, and a permit whose worker crashed or was cut off returns only when its lease expires. So a limit holds across a failover too: a deposed worker whose steps may still be running keeps its permits until they lapse, and the new worker waits.

ServerLimits is the server’s table; RemoteLimits is the worker’s LimitBackend, which asks the server asynchronously and wakes waiting steps when the server grants their permit.

The server keeps every waiting ticket in a WaitQueue with the priority and fairness key it was first asked with, so the order is the same as in one process. A worker asks again only for its own best waiting ticket of each limit; any ask from a worker lets the server grant whichever ticket of that worker the queue serves next, and the answer names that ticket.

Modules

op

Structs

RemoteLimits

The worker’s LimitBackend in server mode.

ServerLimits

The server’s limit table.

Enums

Grant

The server’s answer to an acquire.

Constants

CLIENT_SHIFT

A worker’s tickets count up from worker_id << CLIENT_SHIFT, so the bits above name the client that asked.

LEASE_MS

How long a permit lease lasts without renewal.

Traits

LimitWire

Sends limit requests to the server. priority matters only for op::ACQUIRE.