Env::C threads env flashback

[Stas Bekman <st...@stason.org>]

When I've suggested to use Env::C::getenv to debug the problem with env vars, 
and Mark decided to use Env::C::setenv to solve it, I've forgotten to warn you 
that you shouldn't be using this workaround in the threaded env. If you could, 
modperl would have been doing the right thing in first place.

I've added the following section to Env::C doc and will upload the new version 
(with only the doc change on CPAN shortly).

---
=head1 Thread-safety and Thread-locality

This module should not be used in the threaded enviroment.

Thread-locality: the OS, which maintains the struct C<environ>, shares
it between all threads in the process. So if you modify it in one
thread, all other threads will see the new value. Something that will
most likely break the code.

This module is not thread-safe, since two threads may attempt to
modify/read the struct C<environ> at the same time. I could add
locking if in threaded-environment. However since the lock can't be
seen by other applications, they can still bypass it causing race
condition. But since thread-locality is not maintained, making this
module thread-safe is useless.

If you need to modify the C level of C<%ENV> for all threads to see,
do that before threads are started. (e.g. for mod_perl 2.0, at the
server startup).
---

Also see:
http://perl.apache.org/docs/2.0/user/coding/coding.html#Thread_environment_Issues
__________________________________________________________________
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