perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <>
Subject Re: 2.4 threading branch and apxs missing MPM_NAME
Date Fri, 18 Apr 2014 10:20:51 GMT
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¢,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message