RFORK(2)

✨ RFORK(2) ✨

okay bestie, this is the rfork(2) page from the System Calls Manual and it is literally the blueprint for how new processes get born on this system. buckle up. 🦋

---

🌸 NAME 🌸

rfork — manipulate process resources 💅

---

📚 LIBRARY 📚

Standard C Library (libc, -lc)

---

🎀 SYNOPSIS 🎀

#include <unistd.h>

pid_t
rfork(int flags);

---

👑 DESCRIPTION 👑

so like… forking, vforking, or rforking? those are the ONLY ways new processes get created, periodt. the flags argument you hand to rfork() is the vibe check that decides which resources of the invoking process (the parent) get shared with the new process (the child), or just get reset to their default values. 🌈

and what counts as "resources"? we're talking the open file descriptor table — and yes, when that bad boy is shared, it lets processes open and close files for other processes 😭 — plus the open files themselves.

the flags argument is either RFSPAWN or the logical OR of some subset of the following. not me giving you a whole menu 🍓:

• RFPROC — set it and a brand new process gets created ✨. don't set it and the changes just affect the current process instead. no new baby, just a glow-up.
• RFNOWAIT — set it and the child gets dissociated from the parent 💀. when the child exits it will not leave a status for the parent to collect. go read wait(2) if you want the lore.
• RFFDG — set it and the invoker's file descriptor table (peep intro(2)) gets copied 🫶. otherwise the two processes share one single table. one table, two besties.
• RFCFDG — set it and the new process starts with a clean file descriptor table 🧼. this one is mutually exclusive with RFFDG, so pick a lane.
• RFTHREAD — set it and the new process shares the file descriptor to process leaders table with its parent 👯. it only applies when neither RFFDG nor RFCFDG are set.
• RFMEM — set it and the kernel forces sharing of the entire address space, typically by sharing the hardware page table directly 🔥. the child inherits and shares all the segments the parent process owns, whether they're normally shareable or not. the stack segment is not split (both parent and child return on the same stack) and so rfork() with the RFMEM flag may not generally be called directly from high level languages including C 😭. may be set only with RFPROC. a helper function exists to help with this whole situation and will cause the new process to run on the provided stack — see rfork_thread(3) for the tea. and like, heads up: a lot of code will not run correctly in such an environment. not me warning you twice 💀
• RFSIGSHARE — set it and the kernel forces sharing the sigacts structure between the child and the parent 🫂.
• RFTSIGZMB — set it and the kernel delivers a specified signal to the parent upon the child exit, instead of the default SIGCHLD 📣. the signal number signum is specified by oring the RFTSIGFLAGS(signum) expression into flags. specifying signal number 0 disables signal delivery upon the child exit.
• RFLINUXTHPN — set it and the kernel delivers SIGUSR1 instead of SIGCHLD upon thread exit for the child 👽. this is intended to mimic certain Linux clone behaviour. iykyk.

---

file descriptors in a shared file descriptor table stay open until either they're explicitly closed or all processes sharing the table exit. that's the rule, no cap. 💅

if RFSPAWN is passed, rfork will use vfork(2) semantics but reset all signal actions in the child to default ✨. this flag is what the posix_spawn(3) implementation in libc uses, so it's kind of a big deal.

if RFPROC is set, the value returned in the parent process is the process id of the child process; the value returned in the child is zero. without RFPROC, the return value is zero. process id's range from 1 to the maximum integer (int) value 🔢. the rfork() system call will sleep, if necessary, until required process resources are available. nap time, bestie 😴.

and plot twist — the fork() system call can be implemented as a call to rfork(RFFDG | RFPROC) but is not, for backwards compatibility. iconic behaviour honestly.

---

💖 RETURN VALUES 💖

upon successful completion, rfork() returns a value of 0 to the child process and returns the process ID of the child process to the parent process 👑.

otherwise, a value of -1 is returned to the parent process, no child process is created, and the global variable errno is set to indicate the error 😭.

---

🚨 ERRORS 🚨

the rfork() system call will fail and no child process will be created if:

• [EAGAIN] — the system-imposed limit on the total number of processes under execution would be exceeded 💀. the limit is given by the sysctl(3) MIB variable KERN_MAXPROC. (the limit is actually ten less than this except for the super user, fun little detail fr fr).
• [EAGAIN] — the user is not the super user, and the system-imposed limit on the total number of processes under execution by a single user would be exceeded. the limit is given by the sysctl(3) MIB variable KERN_MAXPROCPERUID.
• [EAGAIN] — the user is not the super user, and the soft resource limit corresponding to the resource argument RLIMIT_NOFILE would be exceeded (peep getrlimit(2)).
• [EINVAL] — both the RFFDG and the RFCFDG flags were specified. told you they were mutually exclusive 🚫.
• [EINVAL] — any flags not listed above were specified. no inventing flags, bestie 🙈.
• [EINVAL] — an invalid signal number was specified.
• [ENOMEM] — there is insufficient swap space for the new process. we are out of room 😭.

---

👀 SEE ALSO 👀

fork(2), intro(2), minherit(2), vfork(2), pthread_create(3), rfork_thread(3)

---

🦋 HISTORY 🦋

the rfork() function first appeared in Plan9. we love an origin story 💜.

---

and that's the whole page, bestie!! 🎀 this one came from the Debian folks and it's dated September 25, 2019 — so like, a little vintage but still absolutely serving. go make some processes, you've got this 🫶✨💖