进程才是并行与隔离的单位：同一 DSH 进程内所有会话与所有 subagent 共用一条 JS 主线程，主线程贴到 98.2% of one core，而整个进程只用掉 2.03 个核

① 所有 subagent 都在父进程内跑，而本随包没有第二种选择

dsh-subagent-in-process-driver/lib/index.js:161 的 startInProcessRun() 直接调 parent.ctx.agents.create()（:180），把子代理交给同文件的 drivePublishedRun()（:195），由它 await child.whenIdle()（:211）；dsh-subagent-spawn-in-process/lib/index.js:35 与 dsh-subagent-fork-in-process/lib/index.js:50 都只是它的薄壳，而这两个 in-process 提供者就是本随包唯一注册过的两个。dsh-subagent*/lib/**/*.js 里 child_process 命中 0——spawn/fork 有若干命中，但都是 provider 名与文档词，不是进程创建。所以「会话数 × 每会话 subagent 数」个 agent 共享同一条 JS 主线程与同一个 V8 堆。（注意口径：这里的「后端」指 subagent 子级后端。随包确有 8 个与 ACP / SDK / Codex / Claude Code 同名的包——dsh-acp / dsh-acp-app / dsh-sdk-app / dsh-sdk-jsonrpc-server / dsh-sdk-minimal / dsh-sdk-protocol / dsh-hooks-codex / dsh-hooks-claude-code——但它们都不是子级后端，没有一个注册 subagent 提供者；上游真正的 ACP / SDK / Codex / Claude Code 子级后端不在这个离线包里。本页只对随包 0.1.5-rc.1 下结论。）

② 主线程是天花板：它贴到 98.2%，而进程只用掉 2.03 个核

K=8 时 MainThread = 98.2% of one core，同刻整个进程 202.6%（= 2.03 个核）——多出来的部分是 4 条 V8Worker（GC/编译）与 4 条 libuv-worker（I/O），不是第二条 JS 执行线程。宿主 256 核、load1 = 9.7（约 4% 利用率）。线程数不是固定的：不变核是 11 条（MainThread + DelayedTaskSche + 4×V8Worker + SignalInspector + 4×libuv-worker），WorkerThread 随 workflow / run_code 起停，同一时刻三个实例量到 11 / 11 / 13；没有任何一条随会话数或 subagent 数增长。

③ 加并发只排队，不提吞吐——用窗口内完成次数立论

三个档各跑一个约 8 秒窗口，窗口内完成的 RPC 次数是 2 / 4 / 0（K=1 / 4 / 8）；K=8 那 8 次全部在窗口之后才完成（ok_after_drain_kN=8）。按闭合循环（完成一次才发下一次）反推，单次 RPC 墙钟时间从 K=1 的约 4 秒升到 K=4 的 4–8 秒、K=8 的 > 8 秒——并发涨 8 倍，吞吐不涨，延迟全部吸收。同刻那条不读任何会话状态的定开销探针，K=1 → K=8 样本数 15268 → 7464（−51%）、p99 0.92 → 3.30 ms（3.6×）、p99.9 7.17 → 20.02 ms（2.8×），K=4 还测到一次 831.9 ms 的停顿。

Title: Every session and every subagent in a DSH Host shares one JavaScript
       main thread - the process, not the session, is the unit of parallelism

Summary
-------
A DSH Host process serves every session and runs every subagent on a single
JavaScript main thread. dsh-subagent-in-process-driver creates children with
parent.ctx.agents.create() inside the same process, and the shipped tree
contains no child_process-based subagent driver. Consequently:

  * one Host cannot use more than about one core of JavaScript, no matter how
    many cores the machine has;
  * adding concurrency to one Host does not add throughput, it only adds queueing;
  * latency for UNRELATED requests served by the same Host degrades as the
    number of concurrent operations grows.

The practical consequence, which is why this is reported: running N sessions in
one Host is NOT equivalent to running N/2 sessions in each of two Hosts, even
at identical total load. Splitting into two Hosts yields a second JS thread.

Environment
-----------
  DSH        0.1.5-rc.1 (shipped lib/, offline bundle @deepseek-ai/dsh)
  Host       Linux x86_64, 256 logical cores, load1 9.7 (about 4% utilised)
  Instance   dsh-user-d - dsh web --profile infra --host 127.0.0.1 --port 4002 (pid 1017149)
  Corpus     2996 session directories on disk for this user
  Node       v24.16.0

Steps to reproduce
------------------
  DSH_HOME=/home/USER/.dsh node main-thread-ceiling-probe.mjs \
      --port 4002 --pid HOST_PID --levels 0,1,4,8 --seconds 8

  load  = K concurrent `session/list` RPCs (a real, unbounded on-disk scan)
  probe = a tight keep-alive loop of `GET /api/ping`, a fixed-cost request that
          reads no session state, so its latency is time the main thread was
          not free for anyone
  cpu   = per-thread CPU from /proc/PID/task/TID/stat

Actual behaviour
----------------
  K  rpc_ok  rpc/s@window  canary_n   p50   p99  p99.9    max  >20ms  main%  other%  proc%
  0       0   0.00@8.1s      14547  0.44  1.13   9.37   92.9      3   69.3     5.0   74.3
  1       2   0.25@8.1s      15268  0.43  0.92   7.17  272.0      6   87.9    50.0  137.9
  4       4   0.50@8.0s       9754  0.62  1.62   9.75  831.9      7   98.4    87.3  185.7
  8       0   0.00@8.0s       7464  0.90  3.30  20.02   93.0      8   98.2   104.4  202.6

  MAIN_THREAD_CEILING main_pct_idle=69.3 main_pct_load=98.2
    process_pct_load=202.6 host_cores=256 host_load1=9.72
    rpc_ok_k1=2 rpc_ok_kN=0 ok_after_drain_kN=8 window_s=8 result=SATURATED

  * The JS MainThread reaches 98.2% of one core, while the WHOLE PROCESS uses
    202.6% - about 2.03 cores - of a 256-core machine at ~4% load. The excess
    over one core is four V8Worker threads (GC/compiler) plus four libuv I/O
    workers, not a second JS execution thread. Note the probe's own canary is
    itself part of this load: with the canary running but no RPC load (K=0) the
    thread already sits at 69.3%, against 4.7% main-thread (11.3% process) measured
    separately on the truly idle instance. Either way the JS thread never exceeds
    one core.
  * Thread count is not fixed. The invariant core is ELEVEN threads
    (MainThread + DelayedTaskScheduler + 4 V8Worker + SignalInspector +
    4 libuv-worker); transient WorkerThreads appear on top while workflows or
    run_code are active (11 / 11 / 13 observed on three instances at the same
    moment). Nothing scales with session or subagent count.
  * QUEUEING, measured without relying on any rate estimate: in an 8 s window,
    K=1 completed 2 RPCs, K=4 completed 4, and K=8 completed ZERO inside the
    window (8 more only after the drain). Per-RPC wall latency therefore grows
    from about 4 s (K=1) to 4-8 s (K=4) to more than 8 s (K=8), while the
    offered concurrency rises 8x. Throughput is flat; latency absorbs
    everything. (An earlier revision of this report quoted a "2.63x speedup"
    from a probe bug that divided a post-drain count by a pre-drain window;
    the probe is fixed and that number is withdrawn.)
  * A probe that touches no session state loses half its throughput as K rises,
    K=1 -> K=8: 15268 -> 7464 samples per window (-51%), p99 0.92 -> 3.30 ms
    (3.6x), p99.9 7.17 -> 20.02 ms (2.8x). One 831.9 ms stall was recorded at
    K=4. K=0 is NOT an idle baseline: the canary loop runs at every level, so
    with no session/list load it is the only load the probe injects. The 69.3%
    is essentially the cost of serving those pings - 14547 in 8.1 s (1796/s),
    about 0.39 ms of main-thread CPU each, under the K=0 row's own 0.44 ms
    p50. This instance's own background load is the 4.7% main-thread figure
    measured separately with no probe running. That is why the monotone arm used
    above is K=1 -> K=4 -> K=8.
  * Control, weaker than a controlled experiment and labelled as such: five
    20 s canary runs against five instances, executed sequentially. The two
    instances whose process CPU was ~0% showed max 15.8 / 16.9 ms and ZERO
    samples above 20 ms; the instances carrying measurable CPU showed max
    99.5 / 106.9 / 257.0 ms with 5 / 10 / 15 such samples.

Expected behaviour
------------------
  Either (a) a Host should be able to use more than one core when several
  sessions and subagents are active, or (b) DSH should document and expose the
  process as the unit of parallelism, with a supported way to shard sessions
  across Hosts, a per-Host concurrency limit / backpressure, and metrics that
  make the ceiling visible.

Code references (0.1.5-rc.1, shipped lib/)
-----------------------------------------
  dsh-subagent-in-process-driver/lib/index.js:161  startInProcessRun()
  dsh-subagent-in-process-driver/lib/index.js:180  parent.ctx.agents.create()
  dsh-subagent-in-process-driver/lib/index.js:211  await child.whenIdle()
  dsh-subagent-spawn-in-process/lib/index.js:35    -> startInProcessRun
  dsh-subagent-fork-in-process/lib/index.js:50     -> startInProcessRun
  (the two in-process providers are the only ones registered in this bundle;
   no child_process-based subagent driver is shipped here)

  dsh-agent-loop/lib/index.js:1040-1043            for await (chunk) ... live.push
  dsh-agent-loop/lib/index.js:1032                 dispatch.emit("agent/assistant-stream")
                                                   - one frame per chunk, no coalescing
  dsh-session-checkpoint-policy/lib/index.js:28    await ctx.sessions.flush(session)
  dsh-session-checkpoint-policy/lib/index.js:64-73 flush awaited on llm/stream,
                                                   tools/execute and agent/pre-step
  dsh-session-persistence-jsonl/lib/index.js:3046-3073 appendLines = open :3049,
                                                   stat :3057, write :3059,
                                                   fsync :3060, close :3054
                                                   (close runs at :3071 in the finally, after the write)
  dsh-session-persistence-jsonl/lib/index.js:2176  DEFAULT_COMPRESSION = "zstd"
  dsh-session/lib/index.js:989,1109,1176,1182      whole event log retained in memory,
                                                   deep copy x2 (data + surface metadata) + freeze per event

  dsh-api-session-controller/lib/index.js:1419-1426 { global: true } listener on
                                                   session/event per follow stream
                                                   (:1420 filters by id only after
                                                    delivery; :1427-1435 session/created
                                                    is a second per-follow one;
                                                    :1436-1444 agent/assistant-stream,
                                                    same shape, same late id filter)
  cordis/lib/index.js:263                          filter(...).map(hook =>
                                                   hook.callback.bind(thisArg))
  dsh-api-gateway/lib/index.js:346-349             JSON.stringify per socket
  dsh-workflow-worker-thread/lib/index.js:311      new Worker(...) - one of the
                                                   off-thread paths that already exist
  dsh-code-runtime-worker-thread/lib/index.js:737  new Worker(...) - run_code
  dsh-session-persistence-jsonl/lib/index.js:1491  new Worker(...) - verification only

Ruled out (all measured)
------------------------
  * Host saturation - 256 cores at load1 9.7 (about 4%). The 202.6% process CPU
    is one saturated JS thread plus GC and I/O helper threads.
  * Network / gateway - loopback direct, the per-user gateway is bypassed; p50
    stays at 0.43-0.90 ms throughout.
  * A frozen event loop - the canary still answers 7464-15268 times per 8 s
    window across the K sweep (15268 at K=1, 7464 at K=8), and issue #9
    separately measured the 2 s heartbeat timer not stalling (2000.0 ms idle;
    2085 ms under 16 concurrent session/list calls, 2026-09-13 on the user-a
    instance). The thread is SATURATED AND QUEUEING, not frozen.
  * One slow request holding the loop - the K=1 level is a closed loop with at
    most one session/list in flight, and there the canary p99 over the 8.1 s
    window was only 0.92 ms (p99.9 7.17 ms), against about 2.0 s for one
    session/list: three orders of magnitude apart, so the scan yields; the
    cost is aggregate CPU, not one blocking call. Caveat: 0.92 ms is a
    whole-window percentile, NOT a conditional percentile over a single
    in-flight scan - the probe has no such mode, so "the tail stays low while
    a scan runs" is an inference, not a measurement.
  * A process-wide mutex - the per-turn path waits on no process-wide lock.
    Persistence does hold a PER-SESSION kernel write lease
    (dsh-session-persistence-jsonl/lib/index.js:652, SessionWriteLease; flock on
    POSIX at :11/:690, a named kernel semaphore at :558 on Windows), but a
    handle takes it once, on its first durable write (:248,
    this.lease ??= await this.storage.acquireWriteLease(this.header)), and it
    belongs to that one session, so it cannot queue turns across sessions.
    Persistence is a true append with one write chain per session and a
    200 ms batching window.
  * Synchronous SQLite - disabled in this deployment (openAt: never); it is also
    not on the per-turn path. Latent risk, not this cause.
  * Per-token durable writes - format v3 coalesces token deltas into
    text-chunks records; the durable write happens once per assistant/message.

Not yet proven
--------------
  * How much MainThread time is GC versus request work. Issue #7 left the same
    question open. Under load the four V8Worker threads total roughly 80% of
    one core, consistent with active concurrent marking, but that does not
    attribute the MainThread time.
  * The two-process configuration. This report measures ONE process; the 2x2
    comparison comes from the reporter's experience plus structural inference.
    No two-process control run was performed.
  * The browser side. The reporter's two configurations also differ in the
    number of browser tabs, hence renderer processes and event loops.

Suggested fixes
---------------
  1. Publish per-Host metrics: process CPU, RSS, event-loop lag, GC time.
     Nothing in DSH or in this deployment exposes them today, so the ceiling
     stays invisible until a user complains.
  2. Add an out-of-process or worker-thread subagent driver and let the profile
     choose it, so a fan-out in one session cannot consume the thread every
     other session depends on.
  3. Bound the fan-out: a per-Host concurrency limit / backpressure for
     concurrent agents, with an explicit "queued" state instead of silent
     degradation.
  4. Replace the per-follow { global: true } listener with an id-keyed
     subscription, so a session's events do not wake every other session's
     followers. This removes a superlinear term rather than shrinking a constant.
  5. Move the fsync + zstd persistence barrier off the interactive path, or make
     the durability level configurable.
  6. Document that the process is the unit of parallelism, and provide a
     supported way to shard sessions across Hosts.