On Mar 23, 2013, at 9:38 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> 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.
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".
> 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.
