Challenge 3: Why mod_php Forces Prefork, and How PHP-FPM Changes That
— Solution Walkthrough

Why traditional mod_php forces Prefork:

mod_php runs the PHP interpreter directly inside each Apache worker
process. That interpreter was never built to be thread-safe -- it
was never designed to have multiple threads inside the same process
executing PHP code at once without risking shared internal state
getting corrupted. Prefork is the one MPM where this is a non-issue,
because each Prefork process handles exactly one connection at a
time with no threading involved at all. Loading mod_php into Worker
or Event, where many threads inside one process are genuinely running
concurrently, risks real crashes or corrupted responses under
concurrent load -- so Apache simply refuses to load mod_php under
anything but Prefork.

How PHP-FPM changes the constraint:

PHP-FPM moves PHP execution out of Apache's own worker processes
entirely. It's a separate, standalone pool of PHP processes running
on its own, and Apache talks to that pool over a socket using
mod_proxy_fcgi rather than running the PHP interpreter inside itself.
Because Apache's own worker processes/threads are no longer the ones
executing PHP code, the thread-safety problem that forced Prefork
simply doesn't apply to Apache anymore -- PHP execution happens in
its own separate process regardless of what Apache's MPM is doing.
This frees Apache to run Event (or Worker), gaining Event's lower
per-connection memory overhead under high concurrency, even on a
PHP-heavy site.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands the actual mechanism
behind the mod_php/Prefork pairing -- a genuine thread-safety
limitation inside the PHP interpreter itself, not an arbitrary Apache
restriction -- and why moving PHP execution into a separate process
(PHP-FPM) removes that limitation entirely rather than just working
around it.