What I understand by "pre-forking daemon" (or more usually, "pre-forking server") is a process with a dynamic number of forked children which manages the child pool so that there are always some idle children waiting for client requests. This is done as a compromise to improve latency without committing vast amounts of memory. If there were a set number of children (say 64) then you might have a situation where all 64 of them are sitting around doing nothing just waiting for a request and hogging memory while it happens. OTOH, if you only fork a child when a request comes in the heavy act of forking introduces latency in the response. By having a stipulated, configurable range of "spare" children you get the best of both worlds. That's the theory, anyway.

Apache 1.x used this method and you can still run Apache 2.x this way if you choose (but most use a threaded MPM instead). PHP-FPM seems to use a similar mechanism as do some nameservers, etc.