perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
Date Tue, 11 Jan 2005 15:02:17 GMT
Gisle Aas wrote:
> Stas Bekman <> 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     mod_perl Guide --->

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

View raw message