A worker on a thread of the parent JVM instead of a process of its own,
for runs that volley.runtime/worker-plan judges too short to pay for a
second JVM. It runs the worker's own loop (volley.shell.worker/serve!)
over in-memory streams: command lines come from the handle's :in
writer, and protocol lines and stray output become events on the
parent's queue exactly as volley.shell.pool makes them from a worker
process's stdout and stderr.
While it runs, System/out and System/err point at its stray output and
System/in at an empty stream, as a worker process sets them up. The
parent prints through the root *out* and *err*, which hold the
original streams, so its output is unaffected. The worker's thread
binds *out*, *err* and t/*test-out* to its stray output instead,
so println on a thread without those bindings goes to the terminal,
as does whatever the thread writes to System/out after kill! (see
In process in doc/design.md).
JVM only: volley.main loads it with requiring-resolve when a run is
in process.
A worker on a thread of the parent JVM instead of a process of its own, for runs that `volley.runtime/worker-plan` judges too short to pay for a second JVM. It runs the worker's own loop (`volley.shell.worker/serve!`) over in-memory streams: command lines come from the handle's `:in` writer, and protocol lines and stray output become events on the parent's queue exactly as `volley.shell.pool` makes them from a worker process's stdout and stderr. While it runs, `System/out` and `System/err` point at its stray output and `System/in` at an empty stream, as a worker process sets them up. The parent prints through the root `*out*` and `*err*`, which hold the original streams, so its output is unaffected. The worker's thread binds `*out*`, `*err*` and `t/*test-out*` to its stray output instead, so `println` on a thread without those bindings goes to the terminal, as does whatever the thread writes to `System/out` after `kill!` (see In process in doc/design.md). JVM only: `volley.main` loads it with `requiring-resolve` when a run is in process.
(start-worker! {:keys [queue test-paths]} id)Start worker id on a daemon thread of this JVM, sending its events to
:queue as volley.shell.pool/start-worker! does, :worker/exit last.
:test-paths are the suites' test paths this JVM's classpath lacks: a
worker process has them on its classpath, so they are added here first
(volley.shell.jvm/add-classpath!), and the thread gets that loader as
its context class loader for Java code that asks for one.
Returns a handle for volley.shell.pool/send!, stop! and kill!,
with the thread itself under :thread. A thread cannot be killed:
kill! reports the exit at once and interrupts it. The var it was in
still ends, but the worker starts no further var and runs no shutdown
hook, and whatever it still sends goes to a worker the run has dropped.
Start worker `id` on a daemon thread of this JVM, sending its events to `:queue` as `volley.shell.pool/start-worker!` does, `:worker/exit` last. `:test-paths` are the suites' test paths this JVM's classpath lacks: a worker process has them on its classpath, so they are added here first (`volley.shell.jvm/add-classpath!`), and the thread gets that loader as its context class loader for Java code that asks for one. Returns a handle for `volley.shell.pool/send!`, `stop!` and `kill!`, with the thread itself under `:thread`. A thread cannot be killed: `kill!` reports the exit at once and interrupts it. The var it was in still ends, but the worker starts no further var and runs no shutdown hook, and whatever it still sends goes to a worker the run has dropped.
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 |