Host-side client of the runtime worker's JSON-line protocol. Dispatch and cancellation stay in Vis; interpreter operations live in the runtime.
Host-side client of the runtime worker's JSON-line protocol. Dispatch and cancellation stay in Vis; interpreter operations live in the runtime.
(claim-reply! peer id)True exactly once per served request id: whoever answers it first — the tool
that finished, or the interrupt that failed it — is the only answer the child
ever reads. A late answer for an id already claimed is dropped here, never sent.
True exactly once per served request `id`: whoever answers it first — the tool that finished, or the interrupt that failed it — is the only answer the child ever reads. A late answer for an id already claimed is dropped here, never sent.
(peer-over channel)A peer over channel: what to read, what to write, who is waiting for a
reply, and which of the peer's requests this side is still serving.
A peer over `channel`: what to read, what to write, who is waiting for a reply, and which of the peer's requests this side is still serving.
(pump! peer serve reason)Read this peer until it closes: a reply settles whoever waits for it, a
request goes to serve on a thread of its own — serving inline would stall
the pump behind a call that is itself waiting on this peer.
On close every pending call fails with reason, because a caller parked on a
child that has died would otherwise wait forever.
Read this peer until it closes: a reply settles whoever waits for it, a request goes to `serve` on a thread of its own — serving inline would stall the pump behind a call that is itself waiting on this peer. On close every pending call fails with `reason`, because a caller parked on a child that has died would otherwise wait forever.
(request! peer message)(request! peer message timeout-ms)Ask the peer message and answer its reply value; its error throws here.
timeout-ms bounds CONTROL messages only; ordinary work waits for its real
result. Pending replies survive caller cancellation until the child replies
or closes, so cancellation can still watch the actual guest execution.
Ask the peer `message` and answer its reply value; its error throws here. `timeout-ms` bounds CONTROL messages only; ordinary work waits for its real result. Pending replies survive caller cancellation until the child replies or closes, so cancellation can still watch the actual guest execution.
(send-line! peer message)Write one message. Synchronized because both a reply and a fresh request can be written from different threads and a torn line is unparseable.
Write one message. Synchronized because both a reply and a fresh request can be written from different threads and a torn line is unparseable.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |