package spawn

  1. Overview
  2. Docs
Spawning sub-processes

Install

Dune Dependency

Authors

Maintainers

Sources

v0.15.1.tar.gz
sha256=9afdee314fab6c3fcd689ab6eb5608d6b78078e6dede3953a47debde06c19d50
sha512=efdb31d5ec5ea36d0bc80224d4ee04e46ce3428d1662870e6cebece92bc313d6eebee378802c0c059dd6e0cafea515308c31b7dfaf04a098eb4566583c1e9ed4

Description

Spawn is a small library exposing only one functionality: spawning sub-process.

It has three main goals:

  1. provide missing features of Unix.create_process such as providing a working directory

  2. provide better errors when a system call fails in the sub-process. For instance if a command is not found, you get a proper [Unix.Unix_error] exception

  3. improve performance by using vfork when available. It is often claimed that nowadays fork is as fast as vfork, however in practice fork takes time proportional to the process memory while vfork is constant time. In application using a lot of memory, vfork can be thousands of times faster than fork.

Published: 19 Apr 2022

README

SPAWN - spawning system process

Spawn is a small library exposing only one function: Spawn.spawn. Its purpose is to start command in the background. Spawn aims to provide a few missing features of Unix.create_process such as providing a working directory as well as improving error reporting and performance.

Errors such as directory or program not found are properly reported as Unix.Unix_error exceptions, on both Unix and Windows.

On Unix, Spawn uses vfork by default as it is often a lot faster than fork. There is a benchmark comparing Spawn.spawn to Unix.create_process in spawn-lib/bench. If you don't trust vfork, you can set the environment variable SPAWN_USE_FORK to make Spawn use fork instead.

Portability

Spawn is expected to be fully portable. However, so far it has only been tested on Linux, OSX and Windows.

Implementation

On Windows, Spawn.spawn simply uses the CreateProcess Windows function.

Under Linux, it uses a custom implementation that relies on fork/vfork followed by execve. Compared to other implementations such as Unix.create_process or the posix_spawn C library call, our implementations supports the following:

  • setting the current working directory of the child process

  • reporting errors from execve to the caller

To report execve errors, our implementation proceeds as follow: just before calling fork or vfork we create a pipe with the O_CLOEXEC flag. After forking, the parent reads from this pipe. If the execve succeeds, the pipe get closed, the read in the parent returns 0 bytes and the parent concludes that the execve succceeded. If the execve fails, the child process sends the error code to the parent via the pipe and exits.

Dependencies (2)

  1. ocaml >= "4.05"
  2. dune >= "2.8"

Dev Dependencies (2)

  1. odoc with-doc
  2. ppx_expect with-test

Used by (9)

  1. async_interactive >= "v0.14.0"
  2. bun = "0.3.2"
  3. core >= "v0.11.1" & < "v0.15.0"
  4. core_unix >= "v0.15.0"
  5. feather >= "0.2.0"
  6. ocaml-lsp-server >= "1.9.0"
  7. shell
  8. shexp >= "v0.11.1"
  9. spin >= "0.8.0"

Conflicts

None