httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: Apache 2 mutiple pools feature request
Date Mon, 01 Mar 1999 14:48:58 GMT
> For what it's worth, the jserv developers have the same problem.  Of
> course, they have an advantage, in that their model is to run a backend
> daemon for java requests, and it's not difficult to configure more than
> one daemon running as different UID's.  

But in my case my backend daemon is an Apache process.  If I simply split
out the PHP code and ran that as a separate process all I would have is
FastCGI which I can do already.  If I do that, I lose a lot of the nifty
features available to me due to the fact that I am part of the httpd
process itself.  Things like the ability to do a sub-request,
per-directory or per-location configuration directives, access to the
various ap_table lists, apache_note passing to the logging module and
other custom modules along with inheriting the log file descriptors and
being able to write to Apache's log files plus a bunch of other stuff I
can't think of right now.  I suppose an IPC protocol could be built to do
pass all this around along with all the logic to control the number of
instances of the daemon, but it seems like a lot of duplicated work when
this has all been done in the Apache code already.

> Formalizing this as something that Apache does makes some sense to me;
> e.g., having a standard interface to back-end daemons for launching (as
> root, setting to a particular UID) / restarting / killing, distributing
> requests, etc.  Maybe even a standard back-end protocol, like what jserv
> uses today.

I am sure this is useful, but it applies more to mod_jserv's architecture
than to PHP and mod_perl.  mod_perl is even less compatible with an
architecture like this since it is tightly integrated with the Apache API
and lets you get right down into the guts of Apache.  Doing this over IPC
doesn't seem feasible to me.


View raw message