Concurrency

The rule

A statement's action starts where it is written. The program waits for it at the first read of the binding it produces. Nothing else is promised, and nothing less is.

That single rule is what makes independent statements overlap. Two two-second requests in one feature set cost about two seconds, not four — nobody reads the first result until after the second request has already been started:

(Dashboard: Reporting) {
    Request the <sales> from the <sales-url>.      (* starts now *)
    Request the <traffic> from the <traffic-url>.  (* starts now, alongside *)

    Compute the <total: sum> from <sales>.         (* waits here for <sales> *)
    Log <traffic> to the <console>.                (* <traffic> is already in *)

    Return an <OK: status> with <total>.
}

Effects stay in order

Deferral is an allowlist of value-producing verbs. Anything observable — Log, Store, Emit, Send, Publish, Return — never defers: it runs at its own statement and forces whatever it reads first. So output appears in source order even though the work behind it did not happen in source order.

Sleep is deliberately excluded from the allowlist, because for Sleep the delay is the effect.

The levels

parallel for each

The one place a program asks for concurrency explicitly.

(* Sequential: one iteration at a time, deterministic order *)
for each <url> in <urls> {
    Request the <page> from <url>.
    Store the <page> into the <page-repository>.
}

(* Concurrent: up to N iterations at a time, non-deterministic order *)
parallel for each <url> in <urls> {
    Request the <page> from <url>.
    Store the <page> into the <page-repository>.
}

(* Explicit bound — match it to what the far end tolerates *)
parallel for each <url> in <urls> with <concurrency: 8> {
    Request the <page> from <url>.
}

Safe inside a parallel iteration: computing, requesting, storing to repositories, emitting events, logging. Unsafe: anything that assumes an ordering between iterations, or that one iteration observes another's effects. Repository writes from concurrent iterations are serialised by the repository — the result is consistent, the order in which entries land is not defined.

What is shared

Two concurrent executions of the same feature set cannot see each other's variables: each execution gets its own binding scope, and bindings are immutable anyway. The only shared, mutable surfaces are repositories and published symbols.

Application-wide limits

with <concurrency: N> bounds one loop; these bound the whole application (ARO-0088 §10a). Work queues at a ceiling — it never fails:

Configure the <application: concurrency> with 8.
Configure the <http-client> with { concurrency: 4, rate: "10/s" }.

Several settings for one category go in one object: two statements naming the same category rebind an immutable binding. A ceiling and a rate are different limits and both apply — one request at a time still exceeds a per-minute quota.

The ceiling counts units of work not already running inside one: every triggered feature set and every parallel for each iteration. Work started beneath a slot-holder runs under that slot, which is what makes the ceiling deadlock-free. The exception is the fire-and-forget event path, where nobody awaits the handler, so it takes a slot of its own. ARO_CONCURRENCY, ARO_HTTP_CONCURRENCY and ARO_HTTP_RATE set the same three.

Turning it off, and tuning it