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
