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 USE_ITHREADS perl leaks pthread_key_t on every + * perl_destruct, which becomes a problem restarts: if the OS
This is not a leak, that's how it is supposed to work.
How can you say that it's not a leak,
What I meant was that the pthread key is normally supposed to stay allocated even after a perl_destruct() (your comment implied otherwise).
if perl allocates the key again and again.
Perl doesn't _want_ to allocate the key again and again--this is why the PL_curinterp check exists. The fact that PL_curinterp is getting reset to NULL when that global lives in a shared object that gets reloaded is the real source of the bug.
right
mod_perl doesn't do anything forbidden, just calls perl_(alloc|parse|destruct|free). It's just that until now the problem was hidden. Any embed app that has to restart will have exactly the same problem.
A pthread_key_t gets allocated for the lifetime of a process or for the duration a shared library remains loaded. It is not something that is local to a single perl interpreter as the comment above seems to imply.
Jan and Gisle have already explained that to me :) It was just an old version of the comment I forgot to adjust.
Sorry, I probably did not manage to read all of the thread before pitching in.
I agree, but I just try to provide a workaround for the bug in perl. I can't do any ref counting on behalf of perl.
But the workaround is not entirely harmless. Gisle's fix is certainly better, so why not include that within mod_perl?
If you look at my latest patch, it's exactly that: http://marc.theaimsgroup.com/?l=perl5-porters&m=110548418315028&w=2
An even better approach might be to make Perl use pthread_once() to allocate its perl_key instead of relying on PL_curinterp being a never-NULL variable. Doing this might actually make Gisle's fix unnecessary. This will also probably make it unnecessary to call pthread_key_delete() anywhere.
Sounds like an excellent idea to me.
On second thought, that idea won't fly without convolutions that aren't needed by Gisle's patch, because PL_thr_key is "forgotton" when the shared object is reloaded (PL_thr_key suffers the same fate as PL_curinterp because both live in the same shared object). So to make that approach work, you'd need to remember/restore PL_thr_key when the shared object is unloaded/reloaded.
Yes, you are again correct, Gurusamy.
So I think Gisle's patch is in fact the simpler/more elegant fix here.
Unfortunately it's not portable (talking about inclusion on perl-core).
I think mod_perl could also consider avoiding the unloading of the perl code to avoid this problem. IOW, whichever shared object contains these perl globals is never dlclose()d for the lifetime of the process.
No, thank you, mod_perl1 does something similar and it's a cause of various unresolved memory leaks on certain platform, where apparently the non-unloading doesn't work quite well.
-- __________________________________________________________________ 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]
