Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

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 po

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Gisle Aas wrote: 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 arrangem

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Gisle Aas <[EMAIL PROTECTED]> writes: > >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 do

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

I can't figure out whether PL_thr_key is a static global that survives perl_destruct and perl_free? If it does than this should work: Index: src/modules/perl/mod_perl.c === --- src/modules/perl/mod_perl.c (revision 124805) +++ src/mo

RE: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

On Tue, 11 Jan 2005, Nick Ing-Simmons wrote: > Gisle Aas <[EMAIL PROTECTED]> writes: >> >> 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

RE: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

On Tue, 11 Jan 2005, Stas Bekman wrote: > 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? Th

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Stas Bekman <[EMAIL PROTECTED]> writes: > I can't figure out whether PL_thr_key is a static global that survives > perl_destruct and perl_free? It is. because you find it declared in perlvars.h under the following heading: -->%-

RE: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Jan Dubois <[EMAIL PROTECTED]> writes: >On Tue, 11 Jan 2005, Nick Ing-Simmons wrote: >> Gisle Aas <[EMAIL PROTECTED]> writes: >>> >>> 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_curinte

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Gisle Aas wrote: Stas Bekman <[EMAIL PROTECTED]> writes: I can't figure out whether PL_thr_key is a static global that survives perl_destruct and perl_free? It is. because you find it declared in perlvars.h under the following heading: -->%-

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Jan Dubois wrote: On Tue, 11 Jan 2005, Stas Bekman wrote: 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

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Stas Bekman <[EMAIL PROTECTED]> writes: > The latest version is: > > Index: src/modules/perl/mod_perl.c > === > --- src/modules/perl/mod_perl.c (revision 124805) > +++ src/modules/perl/mod_perl.c (working copy) > @@ -573,6 +573,17 @@

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Gisle Aas wrote: Stas Bekman <[EMAIL PROTECTED]> writes: The latest version is: Index: src/modules/perl/mod_perl.c === --- src/modules/perl/mod_perl.c (revision 124805) +++ src/modules/perl/mod_perl.c (working copy) @@ -573,6 +573,17

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

On Tue, 11 Jan 2005 14:55:12 EST, Stas Bekman wrote: >> The '#ifdef ALLOC_THREAD_KEY' is wrong AFAICT; this macro will always >> be defined. Testing PL_thr_key as a boolean is outside of the spec of >> what pthreads define. PL_curinterp will be set if the key has >> initialized. That's a better t

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Gurusamy Sarathy wrote: On Tue, 11 Jan 2005 14:55:12 EST, Stas Bekman wrote: The '#ifdef ALLOC_THREAD_KEY' is wrong AFAICT; this macro will always be defined. Testing PL_thr_key as a boolean is outside of the spec of what pthreads define. PL_curinterp will be set if the key has initialized. That'

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

On Tue, 11 Jan 2005 20:32:13 EST, Stas Bekman wrote: >Gurusamy Sarathy wrote: >> On Tue, 11 Jan 2005 14:55:12 EST, Stas Bekman wrote: >>>+++ src/modules/perl/mod_perl.c (working copy) >>>@@ -573,6 +573,17 @@ >>> MP_threads_started = 0; >>> MP_post_post_config_phase = 0; >>> >>>+/* with

Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded

Stas Bekman <[EMAIL PROTECTED]> writes: > Gisle Aas wrote: > > Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>The latest version is: Looks perfect to me. --Gisle > >>Index: src/modules/perl/mod_perl.c > >>=== > >>--- src/modules/