Re: mod_perl 2 APache 2.0 MPM
Sinclair, Alan (CORP, GEAccess) wrote: All, Starting to strike the first blows with Apache 2.0. I am now wondering about thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache config ? Why using the future tense, it does support the threaded mpm pretty much from the very beginning. re: thread-safety see: http://perl.apache.org/search/swish.cgi?query=thread-safesbm=SecIsubmit=search __ Stas BekmanJAm_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
Re: Mod_perl and Apache 2.0
Well, from the looks of the cvs commits, doug seems to be compiling mod_perl under apache 2.0 quite regularly :) With the complete rewrite there's been plenty of work to do. The word on it is here: http://perl.apache.org/~dougm/modperl_2.0.html its still in heavy development by doug - i would say the best thing to do is watch the commits if you want to keep up with it. sterling On Wed, 28 Feb 2001, Jeffrey A. Stuart wrote: Has anyone tried compiling mod_perl under apache 2.0? Also, what is the word on mod_perl 2.0? -- Jeff Stuart [EMAIL PROTECTED]
Re: mod_perl on Apache 2.0
On Wed, 3 Nov 1999, Jeffrey Baker wrote: There was a short discussion a while ago about getting mod_perl working with Apache 2.0. Since Apache 2.0 can actually be built and run on a few platforms now, I think it is worth taking a lot at this for real. I started to fiddle with 5.005_63 and perl_clone(), running concurrent interpreters in seperate threads. it didn't core dump, like old MULTIPLICTY Perls would, but didn't work quite right either. sarathy says it's not quite ready yet, but it looks very promising from what I've seen so far. I hope to start looking into 2.0 things once I catch up here, and get 1.22 released.
RE: mod_perl on Apache 2.0
I'm assuming that Perl itself is reentrant, since it has been embedded in multithreaded environments before (IIS). Hopefully someone can comment on that. Perl 5.005 has experimetal thread support, Perl 5.006 might be stable enought to really use it. What ActiveState has done for IIS, is to pack the Perlinterpreter in a single C++ object (compile Perl with PERL_OBJECT) and now every request can get his own private Perlinterpreter. This model (maybe a pool of Perlinterpreters) may also work for mod_perl. Jochen Wiedman already has done some work on make mod_perl compile with a Perl that is build with PERL_OBJECT, but a lot of work is left... Gerald --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
Re: mod_perl on Apache 2.0
"C. Jon Larsen" wrote: One of the main reasons I use mod_perl is because of the pre-fork caching I can do in the parent that the children can share cheaply. I take huge data structures and assemble them in ram as read-only databases (read hash tables) that are much faster and simpler to access than sql (I use sql only where my data is read/write). With all this talk about threaded perl interpreters what I'd like to be sure of is that in Apache 2.0 my model does not break. Can each private perl interpreter keep its cached (shared) data structures in memory ? Most of my mod_perl processes are big - 10-12 MB, but easily 90+ percent of that is shared. I like this setup, and want to be sure that apache 2.0 does not break this in any way. threads ? are they really appropriate for everyone ? can the old behavior be maintained ? If not, then we would seem to be moving to a more php-like environment, which would be a major bust for me. I can triple (sometimes more) the performance of my handlers by packing my data that is read-only into memory, and using sql only as needed ! Any comments ? Am I off base ? Worrying without cause ? No, you certainly aren't off base. These are precisely the issues that need to be worked out. Apache 2.0 doesn't have a fixed process model. It has a modular multi-process model, or MPM. All of the MPMs so far have n processes and p threads per process. You could have a purely threading Apache (n=1, p=1..*), or a classic Apache (n=1..*, p=1), or something in between. Threads could be kernel threads, pthreads, userland threads, lightweight processes, or something else. Obviously when you are deploying Apache, you need to pick one of the MPMs. Doug indicated earlier that he wanted to make mod_perl work with all MPMs, so any work we do is going to need to be general. If your work relies on pre-fork caching of data, then you will be able to use Apache 2.0 with a pre-fork MPM. Of course, you could also stick with Apache 1.3.x indefinitely. It is, after all, a fine product. You mention that your data structures are read-only. I don't think you are going to have any problems with the thread model, because read-only data is inherently thread safe. The problems don't happen until you are trying to do mixed reading and writing with the same data structure by multiple threads. Hope that answers some questions, Jeffrey
RE: mod_perl on Apache 2.0
Perl threads have nothing to do with OS level threads. They aren't native; they're part of the language itself and don't depend or rely on POSIX threads, native threads, or other such things. In particular, Perl threading doesn't mean that Perl is thread safe. Yes, Perl threads are not OS threads. I am not an thread expert, but Perl threads depends on OS threads, so it maybe possible to "attach" a Perl thread to an OS thread (sometime in the future, when Perl threads are stable) What Doug has said we'll do, and what makes sense, is have a Perl interpreter in memory for each thread. With Perl compiled with -DMULTIPLICITY, we can have multiple interpreters in a single process. They will still benefit from code sharing and such in memory, but there will be per-thread overhead. Plus, AFAIK, no Perl distribution comes shipped with multiplicity, so we'll likely have to require Perl recompilation before mod_perl compilation. This is the way to go for now. We can use -DMULTIPLICITY or -DPERL_OBJECT, that doesn't matter, both will allocate a number of Perl interpreters and they could be assign to a particular thread. Gerald
Re: mod_perl on Apache 2.0
Matt Sergeant wrote:
On Thu, 04 Nov 1999, Jeffrey Baker wrote:
I'm assuming that Perl itself is reentrant, since it has been embedded
in multithreaded environments before (IIS). Hopefully someone can
comment on that.
This work was based on PERL_OBJECT support, which is currently only
available on windows. It's a perl interpreter wrapped up in a C++ object so
that the whole thing is reentrant. For 5.6 I believe a similar
functionality but in C is being added (or is moving out of experimental
mode) called MULTIPLICITY.
I believe -DMULTIPLICITY is already in 5.005_03. Check "man perlembed".
Now suppose we have more than one interpreter instance
running at the same time. This is feasible, but only if
you used the -DMULTIPLICITY flag when building Perl. By
default, that sets PL_perl_destruct_level to 1.
Let's give it a try:
#include EXTERN.h
#include perl.h
/* we're going to embed two interpreters */
/* we're going to embed two interpreters */
#define SAY_HELLO "-e", "print qq(Hi, I'm $^X\n)"
int main(int argc, char **argv, char **env)
{
PerlInterpreter
*one_perl = perl_alloc(),
*two_perl = perl_alloc();
char *one_args[] = { "one_perl", SAY_HELLO };
char *two_args[] = { "two_perl", SAY_HELLO };
perl_construct(one_perl);
perl_construct(two_perl);
perl_parse(one_perl, NULL, 3, one_args, (char **)NULL);
perl_parse(two_perl, NULL, 3, two_args, (char **)NULL);
perl_run(one_perl);
perl_run(two_perl);
perl_destruct(one_perl);
perl_destruct(two_perl);
perl_free(one_perl);
perl_free(two_perl);
}
--
Jeffrey W. Baker * [EMAIL PROTECTED]
Critical Path, Inc. * we handle the world's email * www.cp.net
415.808.8807
