>
> 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
