perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gisle Aas <gi...@ActiveState.com>
Subject Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
Date Tue, 11 Jan 2005 10:37:24 GMT
Stas Bekman <stas@stason.org> 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?

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

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

--Gisle

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message