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

[Jed Brown]

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

> We could
>
> 1) keep things the way they are (one could continue to use --ts_type
> [libraryname:]functionname)
> 2) pass the flag false to PetscFunctionListFind() for all the XXXSetType()
> calls so that only string names of registered types can be used for
> constructors not constructor function names (removing support for using
> --ts_type [libraryname:]functionname)
> 3) Strip all support for alternatively search of the executable and
> libraries for a function name when the requested string name of the type is
> not found from PetscFunctionListFind() (simplifying unneeded code)
>
> A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus
> always store the function pointer in the function list, rather than just
> the string name.
> (simplify unneeded code and remove confusing code)
>

What is required for a shared library to implement an XCreate_Y() function?
Surely it must (a) be linked to PETSc, thus able to call PETSc functions,
and (b) really intend that XCreate_Y be an entry point for this purpose.

Given these two assumptions, I think it is very reasonable for the shared
library to call XRegister("y",XCreate_Y);

Now how should we get those shared libraries loaded? Pretty much all plugin
or dynamic loading systems that I'm aware of would place it in a search
path. Now do we always load all the shared libraries to make sure we have a
complete list? That's possible, but the number of loads can be significant.
Think of Emacs as an example. It provides two constructs

  (require 'feature "filename")

  (autoload 'symbol-name "filename" "Documentation string")

The first case is analogous to calling PetscDLLibraryOpen(). The second is
roughly being provided by the ability to use arbitrary strings, which is
not collision-free. I think replacing it with an "autoload" mechanism would
be sufficient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130323/51e35172/attachment.html>