FastSpawn(3pm)

💖 FastSpawn — aka Proc::FastSpawn 💖

okay bestie, buckle up, this is Proc::FastSpawn, and it lives in the User Contributed Perl Documentation collection (so you know it's a community baddie, not core). She's tiny, she's fast, she's about to make your subprocess game unrecognizable. 🦋

---

✨ NAME ✨

Proc::FastSpawn — fork+exec, or spawn, a subprocess as quickly as possible. that's it, that's the whole vibe. ⚡

---

✨ SYNOPSIS ✨

use Proc::FastSpawn;

# simple use
my $pid = spawn "/bin/echo", ["echo", "hello, world"];
...
waitpid $pid, 0;

# with environment
my $pid = spawn "/bin/echo", ["echo", "hello, world"], ["PATH=/bin", "HOME=/tmp"];

# inheriting file descriptors
pipe R, W or die;
fd_inherit fileno W;
my $pid = spawn "/bin/sh", ["sh", "-c", "echo a pipe >&" . fileno W];
close W;
print <R>;

look at her go 🫶 simple spawn, spawn with env, spawn with inherited fds. chef's kiss.

---

✨ DESCRIPTION ✨

okay so the whole point of this module is simple: she is small (in scope AND footprint, she's not doing too much 💅), and her one job is to spawn a subprocess asynchronously, as efficiently and/or as fast as humanly possible. like, basically the same thing as calling fork+exec on POSIX, except — fingers crossed 🤞 — faster than those two syscalls.

but wait, there's more (there's always more, bestie). Apart from the fork overhead thing, this module ALSO lets you fork+exec programs in situations where otherwise you straight up couldn't. example?? if you're using POSIX threads in your perl process, then ngl it generally isn't safe to call fork from perl. but it is safe to use this module to execute external processes. slay.

and if neither of those problems is a you-problem? then you can safely ignore this module. no hard feelings, we're all busy. 😌

so then. when is fork+exec not fast enough, how do you do it faster, and why would it even matter?? let's unpack 🧚

Forking a process requires making a complete copy of a process. And even though almost every implementation only copies page tables and not the memory itself, it's still not free. for example, on the author's 3.6GHz amd64 box, they can fork a 5GB process only twenty times a second. for a real-time process that has to meet stricter deadlines?? that's way too slow, embarrassing honestly. and for a busy big web server, starting CGI scripts could mean unacceptable overhead. 💀

the workaround is using vfork — except this function isn't very portable, but it does avoid that memory copy that fork has to do. some systems have an optimised implementation of spawn, and some systems have literally nothing. it's giving inequality.

and THIS module's whole thing is abstracting all those differences away. periodt. ✨

now, what improvements should you actually expect? on that 3.6GHz amd64 box this module was originally developed on, a 3MB perl process (which is basically just perl + Proc::FastSpawn) takes 3.6s to run /bin/true 10000 times using fork+exec, and only 2.6s when using vfork+exec. in a 22MB process, the difference is already 5.0s vs 2.6s, and so on and so on. the gap just keeps growing, it's giving main character energy 📈

---

✨ FUNCTIONS ✨

all of the following functions are currently exported by default. no imports needed, she comes ready 🎀

• $pid = spawn $path, \@argv[, \@envp] — creates a new process and tries to make it execute $path, with the given arguments and optionally the given environment variables. basically like calling fork + execv, or execve. it returns the PID of the new process if it worked. on any error, undef is currently returned. ⚠️ heads up: failure to exec might or might not be reported as undef, or it might come at you via a subprocess exit status of 127. so like. check both, bestie, don't get caught lacking.
• $pid = spawnp $file, \@argv[, \@envp] — same as spawn, but it searches $file in $ENV{PATH} like the shell would do. so you don't gotta type the whole path, she'll find it for you 🔍
• fd_inherit $fileno[, $on] — file descriptors can either be inherited by the spawned processes or not, and this is decided on a per file descriptor basis. this module doesn't do anything to any preexisting handles, but with this call you can change the state of a single file descriptor to either be inherited ($on is true or missing) or not ($on is false). note the formatting there, bestie, $on being false means not inherited, not "false-ish, whatever." 😭

free portability pro-tip 🫶 — it seems native win32 perls ignore $^F and set all file handles to be inherited by default. BUT this function can switch that off. iconic behavior.

---

✨ PORTABILITY NOTES ✨

on POSIX systems, this module currently calls vfork+exec, spawn, or fork+exec, depending on the platform. so if your platform has a good vfork or spawn but is misdetected and falls back to the slow fork+exec?? drop the author a note, they want to know 📝

on win32, the _spawn family of functions is what gets used, and the module tries hard to patch the new process into perl's internal pid table — so the pid it returns should work with other Perl functions such as waitpid. also: win32 doesn't have a meaningful way to quote arguments containing "special" characters, so this module tries its best to quote those strings itself. and other typical platform limitations (such as being able to only have 64 or so subprocesses) are not worked around. so like, know your limits 💀

---

✨ AUTHOR ✨

Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/

---

and that's the whole page, bestie!! you're officially a FastSpawn girlie now 💅✨

this lil masterpiece came to you from perl v5.42.3, dated 2026-08-19, and it's FastSpawn(3pm) in the User Contributed Perl Documentation section — go forth and spawn responsibly 🎀🦋💖