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. >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? >> 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. So I think Gisle's patch is in fact the simpler/more elegant fix here. 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. Sarathy [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
