Skip to main content

What fork actually does

Conceptually, parent.fork(n=5) does this:
  1. Pause parent for a few milliseconds.
  2. Take a diff snapshot of parent’s memory — only dirty pages are captured.
  3. Resume parent immediately. The pause window is tiny.
  4. Prepare child memory from the shared base + the diff.
  5. Spawn N children in parallel. Each child gets a per-child rootfs clone (copy-on-write) and shares memory pages with its siblings until they diverge.

Timing

Spawn cost is nearly flat in N because children boot in parallel.

What each child inherits

From the parent’s moment of snapshot:
  • Python REPL state: variables, imported modules, open file handles, any in-memory objects.
  • Filesystem state: everything written to the parent’s rootfs so far.
  • Process tree: every running process in the VM. (Yes, including the Podflare agent + REPL.)
What children do not share after fork:
  • Subsequent writes to memory — isolated between siblings.
  • Subsequent writes to the rootfs — isolated between siblings.
  • Their control channel — each child is independently addressable by its own sandbox id.

Tree-search pattern

diff(other)

Compare filesystem state between two sandboxes (typically two forks of the same parent):
Default compares /root and /tmp; pass paths=[...] to compare elsewhere. Implemented as two parallel sha256sum | sort invocations inside the two sandboxes, diffed SDK-side.

merge_into(winner)

Commit one fork’s state as the new state of the parent:
Under the hood: the parent sandbox is destroyed and the winner takes over the parent’s id.

Limits

  • fork(n) with 1 <= n <= 32. Larger fanouts are deferred until we prove memory pressure at scale.
  • fork() requires a pool-warm parent. Sandboxes created with custom RAM or rootfs skip the pool and can’t be forked.