Processes

A run starts browsers, workers, your apps and their children. When it ends, nothing it started is left running, whether it passed, failed, was interrupted with Ctrl-C or was killed outright.

What danwo cleans up复制标题链接

How an app is stopped复制标题链接

Each app's command runs as the leader of its own process group. A dev command often starts the real server as its child, and stopping the group stops both:

1. the group gets SIGTERM;
2. five seconds later, anything still running gets SIGKILL.

The same happens on Ctrl-C, SIGTERM or SIGHUP. If the worker itself is killed, a small guardian process notices and ends what the worker owned.

Windows has no process groups, so there danwo ends the app's whole process tree with taskkill /T /F. That stop is immediate: Windows has no SIGTERM that a console program obeys, so the app gets no five seconds to close. The guardian works on Windows too, as long as the command danwo started (often cmd.exe running your dev command) still runs: Windows finds a tree through each process's parent, and a process whose parent has exited is no longer part of it.

Start your own processes the same way复制标题链接

An environment that starts a process itself, such as a search server or a mock service, should use spawnOwned. It takes the same arguments as Node's spawn and gives the child a stop():

import { spawnOwned } from "@danwo/sdk"

export async function startSearch(): Promise<() => Promise<void>> {
  const search = spawnOwned(
    "typesense-server",
    ["--data-dir", "/tmp/search", "--api-key", "test"],
    {
      stdio: "inherit",
    },
  )

  return async () => {
    await search.stop()
  }
}

The child gets the same treatment as your apps: its own group, SIGTERM then SIGKILL, and the guardian if the worker dies.

Next复制标题链接