"Gerald Richter" <[EMAIL PROTECTED]> writes:
> > 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...
It seems there's a bit of misinformation on Apache 2.0, Perl threads,
and related issues. So hopefully I can clear some things up:
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.
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.
So... mod_perl will exist in 2.0. We just have a lot of work to do
first, and Perl threads don't help us out in this case.
Chip
--
Chip Turner [EMAIL PROTECTED]
Programmer, ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
