On 18/04/14 11:50, Jan Kaluza wrote: > Hm, do you know why mod_perl needs to know that during compilation? If > it's really used for something, we will have to remove those > MPM-specific #ifdefs and use normal conditionals instead for httpd-2.4.
Perl can be built in 3 different ways: 1) with global data structures. That way it supports only one interpreter per process and only one thread per process. But the resulting Perl is the fastest of the 3. -Uuseithreads -Uusemultiplicity 2) with support for multiple interpreters but leaving out thread synchronization. This is good for environments where conflicting data access can be eliminated by other means. Postgres' perl integration is an example. You can declare 2 backend languages, plperl and plperlu. They need 2 different interpreters. But only one of them can be active at a time. -Uuseithreads -Dusemultiplicity 3) support thread concurrency. -Duseithreads -Dusemultiplicity Historically, modperl supports either 1) or 3). I measured the performance difference between them years ago for perl 5.12. I got 15-20% which is quite a lot. I believe the majority of modperl-backed web servers uses prefork. The best Perl in this context is 1). Up to httpd 2.2 modperl could check if the user tried to use such a Perl with a threaded MPM. It refused to compile in that case. For httpd 2.4, this check does not make sense anymore. Though, I think it would be good to allow the user to build modperl with a Perl built as per 1). I think this should be allowed only upon request such as a command line parameter. In all other cases modperl should refuse to compile with all Perls except for 3). Just my 2¢, Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
