Front page | perl.perl5.porters |
Postings from February 2000
[last attempt bounced, this is a resend]
On Tue, 29 Feb 2000 17:43:41 GMT, Alan Burlison wrote:
>I've implemented this as follows:
>
>1. Added a new XSUB to dl_dlopen.xs called dl_unload_file(). This
>takes a library handle as returned by dl_load_file() and closes it.
>
>2. Added a new function to dlutils.c called dl_unload_all_files().
>This checks to see if the XSUB dl_unload_file() has been defined, and if
>it has it pops all the library handles from dl_librefs and calls
>dl_close_file() on each one. This unloads the dynamically loaded
>libraries in the reverse order to which they were loaded.
>
>3. Modified dl_generic_private_init() in dlutils.c to install
>Perl_call_atexit() handler that calls dl_unload_all_files() when the
>interpreter exits.
>
>4. Documented the above in the appropriate places.
>
>5. Incremented the version number of ExtUtils::DynaLoader to 1.04
Thanks. I have a few questions.
>! SV *sv = get_sv("DynaLoader::dl_debug", 0);
>--- 28,64 ----
>! SV *sv = perl_get_sv("DynaLoader::dl_debug", 0);
Why was this needed? (The preferred name is get_sv(), the long form of
which is Perl_get_sv(aTHX_ ...).)
>+ if ((sub = perl_get_cv("DynaLoader::dl_unload_file", FALSE)) != NULL) {
>+ dl_librefs = perl_get_av("DynaLoader::dl_librefs", FALSE);
>+ while ((dl_libref = av_pop(dl_librefs)) != &PL_sv_undef) {
>+ dSP;
>+ ENTER;
>+ SAVETMPS;
>+ PUSHMARK(SP);
>+ XPUSHs(sv_2mortal(dl_libref));
>+ PUTBACK;
>+ perl_call_sv(sub, G_DISCARD);
>+ FREETMPS;
>+ LEAVE;
I'd s/perl_// those, purely as a matter of style.
And dl_unload_all_files() calling into Perl again via an XSUB instead of
calling a C function directly seems suboptimal. Perhaps the list of
dlopen()ed files should be maintained in the C code, so that you won't
have to depend on the Perl symbol table being around.
> #endif
>+ Perl_call_atexit(&dl_unload_all_files, (void*)0);
> }
s/Perl_// here, or it won't work with multiplicity/usethreads builds.
There was some doubt in my mind whether call_atexit() would do the job
properly. What happens if the dll has allocated SVs? The call_atexit()
callbacks are called after objects are destroyed but *before* the SV
arenas are deallocated. Do you foresee any problems from that?
Sarathy
gsar@ActiveState.com
Thread Previous
|
Thread Next