On Sat 16 Aug 2008, Berg, Eric wrote: > > Now, the environment is a process global resource. So, if > > those values are changed all threads are affected. This is surely > > no what you want. > > When you say that the environment is a global process, global to > what? Each forked process has its own environment, doesn't it? It > seems to me from the brief piece in the User Guide about this and > what you've said, that threaded environments are the real problem > here. In the case of threaded environments, the environment is > shared among all threads, whereas forked processes can and do have > distinct environments per process. Is this correct? That means (as > suggested in the relevant source comments) that a solution for the > forked MPM would be much easier than for those that are threaded. > Right?
Correct. The words "a process global resource" above mean a resource that is global to the process. Btw, another way to manipulate the environment is using the modperl handler instead of perl-script. This way %ENV remains tied to the environment and changes will show up after a perl fork. See also http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Entries_Set_by_Perl_Code Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
