Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Wed, Jan 05, 2005 at 03:21:06AM -0800, Gisle Aas wrote:
> > For a threaded perl the thread key is allocated on the first call to
> > perl_alloc() but there is nothing that frees this key on Unix. On
> > Windows we watch for the DLL_PROCESS_DETACH event and then release the
> > key. This patch implements the same for other platforms using
> > compiler dependent destructors. The patch has been tested on Linux
> > (gcc) and HP-UX (cc and gcc).
>
> This is by implication horribly unportable. Is there no hook that mod_perl
> provides on shared object unloading?
Even if there was a hook in apache that mod_perl could hook into just
before dlclose(), the solution ought to be one that works for any
application that embeds perl. I don't think we want each application
to have to deal with this.
The patch should be harmless for platforms that don't implement the
destructor attribute. They just continue to leak a thread_key on each
reload as before, so I recommend that it is applied until a better
solution is found.
An alternative could be to reference count the perl_{alloc,free} calls
and then free the thread key when it reaches zero. This would then
need some semaphore to keep the update of PL_curinterp and the ref
count race free. This might also have the benefit of actually making
perl_alloc() thread safe; currently if two threads call perl_alloc()
at the same time they might both enter the 'if (!PL_curinterp) {...}'
branch.
> Does anyone know how to do this sort of thing with other compilers?
> eg Sun's compiler?
Google found me this page:
http://docs.sun.com/app/docs/doc/816-1386/6m7qcobkh?a=view#chapter2-48195
Looks like you would have to link libperl with 'cc -zfiniarray=perl_fini ...'
with Sun's compiler to get the same effect.
--Gisle
