From the ai-teammate review round on #226 (bin/dmtools.dart:17).
await AsyncJobPool.instance.boot() runs on EVERY CLI invocation — --version, list, doctor included — spawning 4 engine-worker isolates + a SyncHttpBridge isolate each (~8 isolate spawns + handshakes) before argv dispatch, for a default-off feature (parallelWorkers >= 2).
Concerns:
- failure blast radius: if boot() throws in a constrained env, main() dies before CliDispatcher runs — every non-JS command bricks;
- boot discipline is preserved under a lazier option: the constraint is only that spawning must happen while the event loop is alive, before JS blocks it in an FFI callback. CliDispatcher can boot the pool when the resolved job config carries
parallelWorkers >= 2, just before the JS run — same guarantee, zero cost for everyone else. Alternatively keep the eager boot but guard it so failure degrades to the existing 'unbooted pool → clear JS error' path the tests already exercise.
From the ai-teammate review round on #226 (bin/dmtools.dart:17).
await AsyncJobPool.instance.boot()runs on EVERY CLI invocation —--version,list,doctorincluded — spawning 4 engine-worker isolates + a SyncHttpBridge isolate each (~8 isolate spawns + handshakes) before argv dispatch, for a default-off feature (parallelWorkers >= 2).Concerns:
parallelWorkers >= 2, just before the JS run — same guarantee, zero cost for everyone else. Alternatively keep the eager boot but guard it so failure degrades to the existing 'unbooted pool → clear JS error' path the tests already exercise.