Pools
One of the most important thing to understand about the Apache API is the idea of a pool. This is a grouped collection of resources (i.e., file handles, memory, child programs, sockets, pipes, and so on) that are released when the pool is destroyed. Almost all resources used within Apache reside in pools, and their use should only be avoided after careful thought.
An interesting feature of pool resources is that many of them can be released only by destroying the pool. Pools may contain subpools, and subpools may contain subsubpools, and so on. When a pool is destroyed, all its subpools are destroyed with it.
Naturally enough, Apache creates a pool at startup, from which all
other pools are derived. Configuration information is held in this
pool (so it is destroyed and created anew when the server is
restarted with a kill
). The next level of pool is
created for each connection Apache receives and is destroyed at the
end of the connection. Since a connection can span several requests,
a new pool is created (and destroyed) for each request. In the
process of handling a request, various modules create their own
pools, and some also create subrequests, which are pushed through the
API machinery as if they were real requests. Each of these pools can
be accessed through the corresponding structures (i.e., the connect
structure, the request structure, and so on).
With this in mind, we can more clearly state when you should not use a pool: when the lifetime of the resource in question ...
Get Apache: The Definitive Guide, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.