perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2.0] Win32 ENV still not compatible with mod_cgi
Date Sun, 11 May 2003 10:04:27 GMT
Stas Bekman wrote:
> Joe Schaefer wrote:
> 
>> It appears mod_perl2 treats %ENV as a perl hash instead
>> of a (tied) apr_table (which ARE case-sensitive).
>> IMO that's a bug in modperl2: the offending file is modperl_env.c, 
>> which populates a perl hash from r->process_env instead of tying an 
>> APR::Table
>> to it.  Anyone know why we're doing that?
> 
> 
> Because environ is not thread-local. See the comments in modperl_env.c 
> line 219.
> 
> /*
>  * XXX: what we do here might change:
>  *      - make it optional for %ENV to be tied to r->subprocess_env
>  *      - make it possible to modify environ
>  *      - we could allow modification of environ if mpm isn't threaded
>  *      - we could allow modification of environ if variable isn't a CGI
>  *        variable (still could cause problems)
>  */
> /*
>  * problems we are trying to solve:
>  *      - environ is shared between threads
>  *          + Perl does not serialize access to environ
>  *          + even if it did, CGI variables cannot be shared between 
> threads!
>  * problems we create by trying to solve above problems:
>  *      - a forked process will not inherit the current %ENV
>  *      - C libraries might rely on environ, e.g. DBD::Oracle
>  */

Please correct me if I'm wrong, but I think in the mod_perl domain, the only 
hazard is when a mod_perl handler running inside a specific thread, modifies 
%ENV. Currently mod_perl handlers modifying %ENV, aren't affecting the global 
environ. So if we can keep the retrival using the normal tied interface (which 
solves Steve's problem), and have a special workaround for storing, by storing 
local changes not in the process-global environ, but elsewhere.

If that's correct: what do you think about the following solution

- non-threaded mpms:
   go back to the fully-tied interface
- threaded mpms: modified tied interface
   = the STORE method:
     - store the env pair in the thread-local (TLS, but access is expensive) 
or request specific variable (for example a magic attached to $connection).
   = the FETCH method:
     - first lookup in the local table, if failed lookup in the global environ.
     but would prefer to do it the other way around, since the first
     lookup might be slow and hardly ever used

I'm not sure what is a more effective solution for the thread-local storage, 
either using something similar to modperl_global_get_server_rec or attaching 
magic somewhere.

Hmm, I wonder how hard would it be to attach more magic to %ENV itself. So 
it'll have the normal TIED magic for environ, plus '~' magic for local %ENV 
overrides.

p.s. I've just read the spec on glibc 2.3 and it seems that quite soon, we 
won't have this limitation of TLS, since glibc supports __thread compiler 
hints, which will create thread local variables, without using POSIX thread 
key access. (read it'll work at the same spead as automatic variables).

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message