The big idea
Interrupts wake the kernel; the kernel wakes processes; the scheduler decides when they run.
A sleeping or blocked process does not receive a network packet directly.
The kernel receives the packet first, buffers it, updates kernel data structures, and only then decides whether the blocked process should be made runnable again.
In other words:
I/O wakes processes; processes never “catch” interrupts themselves.
This is one of the core illusions created by the OS.
Step-by-step: what actually happens
Let’s assume a user process is blocked in a recv() call on a TCP socket.
1. The process is blocked (sleeping)
- The process has executed a system call (e.g.
recv()). - The kernel determines that no data is available.
- The process is:
- Removed from the ready queue
- Placed into a wait queue associated with that socket
- Marked as blocked / sleeping
- The CPU is context-switched to another runnable task.
Crucially:
- The process is not scheduled
- The process cannot run
- The process cannot handle interrupts
2. A network packet arrives
- The network interface card (NIC) receives the packet.
- The NIC raises a hardware interrupt.
- The CPU immediately switches to kernel mode and runs the interrupt handler.
At this point:
- No user process is involved.
- The blocked process is still asleep.
3. Kernel networking stack processes the packet
Inside the kernel:
- The packet is validated and decoded (Ethernet → IP → TCP/UDP).
- The kernel identifies the destination socket.
- The packet data is placed into the socket’s receive buffer (kernel memory).
This is resource allocation in action:
- Memory buffers are consumed
- Network queues are managed
- Back-pressure may apply if buffers are full
4. The blocked process is woken up
If the socket now has data:
- The kernel checks the socket’s wait queue
- Any process blocked on that socket is:
- Marked READY
- Moved back into the run queue
This transition is often called a wake-up event.
Important nuance:
- The process is eligible to run
- It does not run immediately unless:
- It has higher priority, or
- The scheduler decides to pre-empt the current task
5. The scheduler decides when it runs
At the next scheduling decision:
- The scheduler compares:
- Current running task
- Newly awakened task
- Based on policy (priority, fairness, deadlines), it may:
- Continue current task, or
- Pre-empt and context-switch
Only now does the process resume execution and return from recv() with data.
Key clarifications students often miss
“Does the packet wake the process directly?”
No.
The kernel wakes the process, not the packet.
Packets wake kernel logic; kernel logic wakes tasks.
“Can a sleeping process miss packets?”
No (within limits).
Packets are buffered in kernel space until:
- The process reads them, or
- Buffers overflow (then packets may be dropped)
This buffering is a core resource allocation responsibility of the OS.
“What if many packets arrive?”
The kernel may:
- Batch interrupts
- Use NAPI / polling
- Apply QoS, shaping, or flow control
- Delay wake-ups to avoid thrashing
This is where high-throughput multitasking becomes hard.
How this maps directly to A1.3.5
Multitasking
- The blocked process is not runnable
- Interrupts are handled asynchronously
- Wake-ups reintroduce tasks into scheduling competition
Resource allocation
- Kernel buffers memory for packets
- Network queues arbitrate bandwidth
- Scheduler arbitrates CPU access once the task wakes
Challenges
- Too many wake-ups → scheduling overhead
- Too much buffering → memory pressure
- Priority interactions → latency or starvation
One-sentence mental model
Interrupts wake the kernel; the kernel wakes processes; the scheduler decides when they run.
That sentence alone resolves about half of student confusion in this topic.