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

[Barry Smith]

  Consider the following behavior

~/Src/petsc/src/ts/examples/tutorials  barry/fix-dynamic $ ./ex7 -ts_type KSPCreate
[0]PETSC ERROR: --------------------- Error Message ------------------------------------
[0]PETSC ERROR: Null argument, when expecting valid pointer!
[0]PETSC ERROR: Null Pointer: Parameter # 2!
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Petsc Development GIT revision: 4e2e63373ef067af348e1d051da38b259e4d3643  GIT Date: 2013-03-21 12:36:44 -0500
[0]PETSC ERROR: See docs/changes/index.html for recent updates.
[0]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
[0]PETSC ERROR: See docs/index.html for manual pages.
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: ./ex7 on a arch-dynamic named Barrys-MacBook-Pro.local by barrysmith Thu Mar 21 21:57:22 2013
[0]PETSC ERROR: Libraries linked from /Users/barrysmith/Src/PETSc/arch-dynamic/lib
[0]PETSC ERROR: Configure run at Thu Mar 21 21:30:07 2013
[0]PETSC ERROR: Configure options --download-mpich --with-shared-libraries --with-dynamic-loading --with-single-library=false
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: KSPCreate() line 727 in /Users/barrysmith/Src/PETSc/src/ksp/ksp/interface/itcreate.c
[0]PETSC ERROR: TSSetType() line 67 in /Users/barrysmith/Src/PETSc/src/ts/interface/tsreg.c
[0]PETSC ERROR: TSSetTypeFromOptions() line 43 in /Users/barrysmith/Src/PETSc/src/ts/interface/ts.c
[0]PETSC ERROR: TSSetFromOptions() line 112 in /Users/barrysmith/Src/PETSc/src/ts/interface/ts.c
[0]PETSC ERROR: main() line 95 in src/ts/examples/tutorials/ex7.c

  This happens because all the different XXXSetType() routines call PetscFunctionListFind() with the flag to alternatively search the executable and dynamic libraries for functions passing the name passed it.   The original plan was so that users at runtime could load their own custom versions, for example -ts_type mydynamiclib:TSCreate_MyCoolTS.  In the past I've run -ts_type rows and gotten the same crash because my libraries happened to have a function named rows.

Thus one can indicate constructors in two ways (Barry doesn't like two ways to do anything:-)), by the string name if the constructor function was registered with XXXRegister() or if dynamic libraries are enabled, directly by the name of the constructor function. 

Just to add a little more complexity, if PETSc is built with --with-dynamic-loading when functions are registered with PetscFunctionListAdd() the string name of the function is kept in the list, but not the actual function pointer. Then, if PetscFunctionListFind() locates the registered string name, the function pointer is dynamically loaded using the string version of the function. 

Also when opening a dynamic library, PETSc automatically calls  a function within that the library that __can__ register any types whose constructors are in that library. Thus if all available types are registered in all dynamic libraries then the support for directly indicating the constructor function name is not needed (though perhaps useful?).

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 say you,

  Barry