[petsc-dev] too much dynamic loading; a chance to simplify and remove some code?

Jed Brown jedbrown at mcs.anl.gov
Sat Mar 23 23:06:45 CDT 2013


On Sat, Mar 23, 2013 at 10:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> >   We currently have -dll_pre/append PetscDLLibraryPre/Append() allowing
> users to indicate libraries to open. We don't have a concept of a path of
> directories to look for libraries. Conceivably we could introduce a path
> and only march through the path opening each library if the requested type
> is not found yet. This would mean in the "smallest change from current
> source code" implementation that whenever PetscFunctionListFind() (for
> types) does not find a request it opens the next library and then looks
> again. One issue for that is if the PetscFunctionListFind() is not run on
> PETSC_COMM_WORLD, some processes will open more libraries than others; this
> makes the "search through the path only as needed" a dangerous thing due to
> the parallelism. I'd be inclined to just open all the dynamic libraries in
> PetscInitialize() and tell people for performance reasons they may want to
> limit the path for "big runs".
> >
>
>     Since we won't be searching through the libraries for symbols we can
> get rid of the prepend,append stuff as well and just have a command line
> option for opening libraries.


Yup, sounds good. I don't like searching because of the collective load
problem.

We could add PetscDLLibraryOpenTree() that would recursively open
subdirectories and load all the shared libraries. This would let an
application selectively load any plugins they were interested in as
automatically as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130323/6c68c242/attachment.html>


More information about the petsc-dev mailing list