A Worker which can spawn both client and nemesis-specific workers based on the :client and :nemesis in a test.

Should this operation be journaled to the history? We exclude :log and :sleep ops right now.

When the generator is :pending, this controls the maximum interval before we’ll update the context and check the generator for an operation again. Measured in microseconds.

Takes a test with a :store :handle open. Causes the test’s reference to the :generator to be forgotten, to avoid retaining the head of infinite seqs. Opens a writer for the test’s history using that handle. Creates an initial context from test and evaluates all ops from (:gen test). Spawns a thread for each worker, and hands those workers operations from gen; each thread applies the operation using (:client test) or (:nemesis test), as appropriate. Invocations and completions are journaled to a history on disk. Returns a new test with no :generator and a completed :history.

Generators are automatically wrapped in friendly-exception and validate. Clients are wrapped in a validator as well.

Automatically initializes the generator system, which, on first invocation, extends the Generator protocol over some dynamic classes like (promise).

Creates communication channels and spawns a worker thread to evaluate the given worker. Takes a test, a Queue which should receive completion operations, a Worker object, and a worker id.

Returns a map with:

:id The worker ID :future The future evaluating the worker code :in A Queue which delivers invocations to the worker

This protocol allows the interpreter to manage the lifecycle of stateful workers. All operations on a Worker are guaranteed to be executed by a single thread.