New State: Process Creation and Admission

Every process that has ever executed on a computer—from the simplest shell script to the most complex database server—began its existence in a single, fundamental state: New. This state represents the critical transition point where a static program transforms into a dynamic, schedulable entity capable of competing for system resources.

The New state is far more than a mere bookkeeping label. It represents a complex orchestration of memory allocation, data structure initialization, security validation, and resource reservation. Understanding this state deeply reveals how operating systems balance resource efficiency with process creation speed, and how design decisions at this level ripple through system performance.

The New state represents a process that has been created but has not yet been admitted to the pool of executable processes. A process in this state exists in a liminal space—it has been acknowledged by the operating system, but it cannot yet compete for CPU time.

Formal Definition

A process is in the New state when:

1. The operating system has received a request to create the process
2. Initial data structures (primarily the PCB) are being allocated and initialized
3. The process has not yet been admitted to the Ready queue
4. No CPU time has been allocated to the process

This state exists because process creation is not instantaneous. Creating a process involves multiple operations—memory allocation, security validation, resource reservation—that take time and may fail. The New state provides a holding area while these operations complete.

Processes don't spontaneously appear—they are explicitly created in response to specific system events. Understanding these triggers reveals the different pathways into the New state and the varying requirements each pathway imposes.

The Four Canonical Creation Triggers

Operating systems textbooks identify four primary events that cause process creation:

Creation Trigger Characteristics

Each trigger has distinct characteristics that affect process creation:

System initialization processes are privileged, often running as root/SYSTEM, with access to hardware and kernel services. They're created before user authentication is possible, so security context is established through boot configuration rather than user credentials.

User-requested processes inherit the user's security context, environment variables, and resource limits. The shell typically performs path resolution, argument parsing, and environment setup before invoking the creation syscall.

Process spawning is the most complex case. The child process must decide what to inherit from the parent (open files, environment, working directory) versus what to reset. UNIX's fork-exec model gives the parent explicit control over this inheritance.

Batch jobs operate in controlled environments with predefined resource allocations. The scheduling system may impose quotas, time limits, and priority adjustments not applied to interactive processes.

The Process Control Block (PCB) is the kernel's representation of a process—a data structure containing all information the operating system needs to manage the process. During the New state, the PCB is allocated and populated with initial values.

PCB Allocation

Most operating systems maintain a pool of pre-allocated PCB structures to accelerate process creation. Allocating a PCB from a pool is O(1), while dynamic allocation might require memory allocator locks and potential page faults.

Key Insight: The PCB is a kernel-space structure. User processes cannot
directly access or modify their own PCB—they can only influence it
indirectly through system calls.

Fields Initialized During New State

The fork() Initialization Path (UNIX)

In UNIX systems using fork(), PCB initialization has a unique characteristic: the child's PCB is largely a copy of the parent's PCB. This is why forked children inherit open files, signal handlers, and environment—these are simply copied from the parent's PCB.

However, certain fields are reset rather than copied:

• PID: Assigned a new, unique process ID
• PPID: Set to the parent's PID (the forking process)
• Resource usage counters: Reset to zero (the child hasn't used any resources yet)
• Pending signals: Cleared (signals pending for parent shouldn't affect child)
• File locks: Not inherited (locks are per-process, not per-file)
• Memory locks: Not inherited (mlock() doesn't transfer)

Copy-on-Write Optimization

Modern UNIX systems don't actually copy the parent's memory during fork(). Instead, both processes share the same physical pages, marked read-only. Only when either process writes to a page is a copy made. This copy-on-write (COW) optimization makes fork() nearly instantaneous, even for processes with gigabytes of memory.

While the PCB represents the process to the kernel, the virtual address space represents the process's computational environment. During the New state, this address space is established—though not necessarily populated with physical memory.

Virtual Address Space Layout

A typical process address space contains several segments:

Lazy Memory Allocation

A crucial optimization: during the New state, the OS typically does not allocate physical memory for the entire address space. Instead, it creates page table entries that are marked "not present." When the process actually accesses a page, a page fault occurs, and only then is physical memory allocated.

This demand paging strategy means:

• Process creation is fast (no copying of executable code)
• Memory isn't wasted on code/data that's never accessed
• Large programs can start quickly even if they use lots of memory later

Page Table Creation

The page table is the data structure that maps virtual addresses to physical addresses. During New state:

1. Top-level page table is allocated (PGD on x86_64: 4KB)
2. Kernel mappings are shared from a global template (not copied per-process)
3. User-space entries are populated lazily or copied from parent (fork) with COW

The page table is one of the few structures that must be allocated during New state because the CPU needs it to translate any memory access the process makes.

Beyond memory, a new process requires various system resources. The New state is when these resources are allocated or inherited from the parent process.

File Descriptor Inheritance

In UNIX systems, by default, open file descriptors are inherited across fork():

• stdin (fd 0): Standard input, typically the terminal
• stdout (fd 1): Standard output, typically the terminal
• stderr (fd 2): Standard error, typically the terminal
• Other open files: Inherited unless marked close-on-exec (O_CLOEXEC)

This inheritance is what makes shell pipelines work. When you type ls | grep foo, the shell:

1. Creates a pipe (two file descriptors: read end and write end)
2. Forks a child for ls, with stdout redirected to pipe's write end
3. Forks a child for grep, with stdin redirected to pipe's read end

Without file descriptor inheritance, inter-process communication would require complex setup.

The Close-on-Exec Flag

Not all file descriptors should be inherited. Consider a server that opens sensitive configuration files—child processes handling untrusted requests shouldn't have access to these files.

The O_CLOEXEC flag (or fcntl(fd, F_SETFD, FD_CLOEXEC)) marks a file descriptor to be automatically closed when the process calls exec(). This prevents accidental leakage of file descriptors to child programs.

Resource Limits (rlimits)

Resource limits constrain what a process can consume:

These limits are inherited during process creation and can be reduced (but not increased beyond the hard limit) by unprivileged processes.

Security context establishment during the New state determines what the process can access throughout its lifetime. This involves user identity, group membership, capabilities, and mandatory access control labels.

User and Group Identity

Every process carries a security identity consisting of:

Real UID/GID (ruid, rgid): The actual user who owns the process. Used for accounting and signals.

Effective UID/GID (euid, egid): Used for permission checks. Usually equals real UID but differs for setuid programs.

Saved UID/GID (suid, sgid): Preserved copy of euid/egid from before exec(). Allows temporary privilege drop and restoration.

Supplementary Groups: Additional group memberships beyond the primary group.

Linux Capabilities

Modern Linux has moved beyond simple root/non-root distinction to fine-grained capabilities. Instead of granting all-or-nothing root access, specific capabilities can be granted:

During New state, capabilities can be inherited from the parent, granted by file capability attributes, or dropped by the process itself.

Mandatory Access Control

Beyond traditional UNIX permissions, systems like SELinux (Linux), AppArmor (Linux), and Sandbox (macOS) impose additional constraints:

• SELinux contexts: Every process runs with a security label (e.g., unconfined_t, httpd_t). The policy determines what labels can access what resources.
• AppArmor profiles: Processes are confined to specific file paths, network access, and capabilities based on executable name.
• macOS Sandbox: Applications declare entitlements; the kernel enforces access based on these declarations.

These contexts are established during the New state and cannot be elevated later (only further restricted).

Not every process that enters the New state successfully transitions to Ready. Admission control is the operating system's mechanism for deciding whether to accept a new process into the system.

Why Admission Control Exists

Resources are finite. If the system creates processes without limits:

• Memory exhaustion causes thrashing (all time spent swapping, no real work done)
• Scheduler overhead grows with process count, degrading all processes
• File descriptor tables fill up, causing I/O failures
• Fork bombs can bring entire systems down in seconds

Admission control prevents system collapse by rejecting or delaying process creation when resources are scarce.

Admission Control Responses

When admission control rejects a process:

Immediate Failure: The fork()/CreateProcess() call returns an error (EAGAIN, ENOMEM, etc.). The parent process must handle this gracefully.

Delayed Admission: In some real-time systems, new processes may wait in the New state until resources become available. This is less common in general-purpose systems.

Priority-based Admission: The scheduler might admit high-priority processes while rejecting low-priority ones under resource pressure.

Long-Term vs Short-Term Admission

Long-term admission (also called job scheduling): Decides which jobs from a batch queue should be initiated. Common in HPC and mainframe environments.

Short-term admission: The immediate decision of whether a fork() should succeed. This is what most developers encounter directly.

In modern systems, long-term admission is often delegated to container orchestrators (Kubernetes) or job schedulers (Slurm) rather than the kernel itself.