develooper Front page | perl.perl5.porters | Postings from February 2000

Re: [PATCH 5.5.660] ExtUtils::DynaLoader dl_unload_file() patch

Thread Previous | Thread Next
Alan Burlison
February 29, 2000 13:26
Re: [PATCH 5.5.660] ExtUtils::DynaLoader dl_unload_file() patch
Message ID:
Gurusamy Sarathy wrote:

> 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_ ...).)

Not according to perlguts it isn't....

| If you know the name of a scalar variable, you can get a pointer to
its SV
| by using the following:
|    SV*  perl_get_sv("package::varname", FALSE);

> >+     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.

Also, not according to perlguts.  I've never written a core patch
before, so I had to use the only documentation to hand, which is
perlguts.  Thank yourself lucky that I figured out the item popped off
@dl_librefs had to be mortalised ;-)  (perlguts virtually always fails
to tell you if a return value is mortal or not).

> 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.

Optimal, no.  Orthogonal, yes.  All the other dl_XXX functions are
declared in the sundry platform-dependent dl_XXX.xs files.  the
Principal Of Least Surprise suggested that dl_unload_file() should be
made to look as similar to its partner dl_load_file() as possible. 
Also, doing this meant that I could check to see if dl_unload_file() was
declared before I tried to call it - meaning that on those platforms
that didn't require it, dl_unload_file() could safely be left
undefined.  You couldn't do this if it was written as a plain C function
- I'd have had to put a stub dl_unload_file() in every dl_XXX.xs
platform variant.  As for efficiency - the overead of calling dlclose()
will dwarf the overhead of calling an XSUB.

As for depending on the Perl symbol table being around - when this patch
was originally discussed this was raised, and I got the distinct
impression that the reason for rejecting my previous patch and
suggesting the use of Perl_call_atexit() was precisely because the
symbol table *would* be around.

> >  #endif
> >+     Perl_call_atexit(&dl_unload_all_files, (void*)0);
> >  }
> s/Perl_// here, or it won't work with multiplicity/usethreads builds.

Perl_call_atexit/call_atexit aren't documented anywhere I could find,
and the only use is in perlapi.c, where it is called as
'((CPerlObj*)pPerl)->Perl_call_atexit(fn, ptr);'
so is that broke too?

> 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?

Pass.  Does that mean that @dl_librefs will have been reclaimed?  If so,
the patch seems to work remarkably well considering it is popping stuff
of a free'd AV.  I don't think the dll allocating SVs has anything to do
with it - dlclose() doesn't do any sort of cleanup (except if you have a
.fini section, but that is probably Solaris-specific).

I wrote the patch based on what I thought was the consensus on the
correct way to do this - was I mislead?

Alan Burlison

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About