Re: embedding and threads.pm
[email protected] (Stas Bekman)
| Newsgroups | perl.ithreads |
|---|---|
| Organization | Hope, Humanized |
| Message-ID | <[email protected]> |
A.Bergman wrote: > > 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