On torsdag, mar 6, 2003, at 23:47 Europe/Stockholm, Stas Bekman wrote:
I've explained this in a separate post: http://archive.develooper.com/[EMAIL PROTECTED]/msg00649.html
The gist of the problem is, under threaded mpm Apache2/mod_perl2. Let's say there are two OS threads T1 and T2 (not ithreads) and one Perl Interpreter P1.
1. threads.pm boots in thread T1 perl Interpreter P1 (all works)
2. threads->self is called from T2 perl Interpreter P1 (segfault)
in the threaded mpm mod_perl2, there is a pool of perl interpreters. So the same interpreter can be used by more than one OS thread. The problem with the threads.pm package, is that it stores its env in the thread's T1 TLS it was booted from and not PerlInterpreter P1's structure. When the same interpreter P1 is used by a different thread T2, PerlInterpreter P1 sees that threads.pm is already loaded, however when it tries to retrieve the ithreads env from TLS it fails, because nothing is stored there and boom, segfault.
Ah of course, we should hang the info of the PerlInterpreter instead.
cool. Does it require a big change?
Any plans for the threads package to have a separate from core life on CPAN? Because if that bug is fixed, perl 5.8.0 will still have it.(and it's crucial to have it fixed if we want to have a working DBI pooling under threaded mod_perl).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
