Stas Bekman <[EMAIL PROTECTED]> writes:
Under mod_perl2 you can have independent pools of interpreters, in which case I doubt you can reuse PL_thr_key, because those interpreters aren't related.
I don't know much about mod_perl2, so perhaps you can explain to me what the arrangement with pools of interpreters is. And what does it mean that interpreters are related?
Under a plain perl program you have a single perl interpreter.
Under a threaded perl program you have one parent interpreter and several clones. Each clone is physically tied to an OS thread.
Under modperl2, you have pools of interpreters. The pools are independent from each other. Each pools is comprised of a parent interpreter and clones. None of the interpreters is tied to an OS thread. Instead at run time, an OS thread may use one interpreter at a time. So you may have 100 OS threads running, with just 5 interpreters (allowing you to use threads for other non-perl things, and tieing an interpreter only when you need it).
So each parent interpeter should be totally independent from other parent interpreters. I'm not sure if sharing the key is possible. Since you will end up with two threads from totally different pools using the same thread key. Or is it just fine?
Isn't that a problem if two unrelated interpeters try to use the same key, sounds like a *very* bad idea under threads. We have enough mysterious crashes under threads, I won't be surprised that this is one of the reasons. I need to write more tests to tell for sure.
The thread key is not property of an interpreter. It is a single global shared between all the threads running in the process space. Same goes for PL_curinterp, it's a true global. The concept of having different interpeters use different thread keys does not make sense.
I see.
Moreover if perl does get fixed, this modperl2 case is certainly going to crash, since it'll destroy the key but other parent interpreters sharing it will be still running. My test program demonstrates that quite clearly.
Are you talking about my "perl_fini" patch as the fix here? The key is not destroyed until the code is about to go (at dlclose time). If other threads are still running they should segfault when the text segment gets unmapped during dlclose, i.e. this can't happen.
Right. So the key delete should happen only once, even though there is more than one parent interpreter.
-- __________________________________________________________________ Stas Bekman JAm_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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
