FWIW, the Python specific hosting module called mod_wsgi for Apache implements named daemon process groups, with ability to control how WSGI applications are delegated to which process group. This includes being able to optionally have process group selected based on value of ENV value set by mod_rewrite. Various directives can optionally be used to limit which process groups can be delegated when using this.
Anyway, not necessarily relevant but may still be of interest. Links to some of the documentation are: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIProcessGroup http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIRestrictProcess Graham 2009/9/23 Rainer Jung <rainer.j...@kippdata.de>: > Sorry for the long mail, especially in case all is well-known. > > While looking for the right way to implement something like FCGIDGroup I > stumbled about something a bit strange in mod_fcgid. > > When looking for an appropriate existing process to handle a request the > following data is used by mod_fcgid: > > - inode > inode num of the wrapper if one is used, > of the request filename otherwise > - deviceid > device id of the wrapper if one is used, > of the request filename otherwise > - share_grp_id > Always 0 if no wrapper is used, > -1 for one of the auth wrappers, > otherwise an incrementing id that is > unique across each wrapper with the same path > (but different vhosts or even only different extensions) > ids between different paths can overlap > - virtualhost: the pointer (!) to > r->server->server_hostname > - uid: retrieved via ap_run_get_suexec_identity > - gid: retrieved via ap_run_get_suexec_identity > > If no process is found, a new one is created and carries the above data > coming from the request (and wrapper) which ran when it was created. > > Going a bit through the history of mod_fcgid, it seems that share_grp_id > was added to support a directive FCGIWrapperGroup (sic!). Later the > directive was removed, and the id was automatically incremented to > ensure separation. > > Again later there was a bug w.r.t. incomplete isolation of the default > env between vhosts, so virtualhost was added, but seems only necessary > for the non-wrapper case. > > It seems there's some potential for improvement concerning sharing of > fastcgi applications. > > 1) Non-wrapper case > > The applications are given by the filenames the requests resolve to. So > the most likely thing that could happen, is that someone wants to share > the process pools for those between vhosts. I guess for this it would be > enough to add FCGIDGroup. It would be optionally used once in vhosts to > set a symbolic name, which will be used to seperate the pools between > vhosts instead of the server_hostname. By choosing the same FCGIDGroup > in several vhosts, one can share the process pool. > > 2) Wrapper case > > The wrapper is configured via its path name and the optional extension > it applies to. At the moment independent pools are used for different > vhosts, but also (!) for different extensions. > > So if we would add FCGIDGroup to a vhost, it would stop the extension > separation. Another possibility would be, to apply FCGIDGroup only to > the non-wrapper case and add some syntax to FCGIWrapper to allow > expressing, which group it belongs to. Unfortunately that directive > already has two optional arguments, one can be detected, because it > starts with a dot, the other one is the fixed string "virtual". The > syntax might get ugly, if we need to safely distinguish three optional > arguments > > Something like > > FCGIDWrapper wrapperpath [groupname] [.extension] [+flag ...] > > and the only flag implemented at the moment is "virtual". > > Regards, > > Rainer > >
