[petsc-dev] Why --with-dynamic-loading?

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>    One early plan was that all the PETSc impls would be in plug-in
>    libraries; so for example the CG code could be in
>    libpetsckspimpl.dylib etc.  Thus requires some refactoring of the
>    code, we've always been too lazy to do, for example the solver
>    specific interface functions like KSPGMRESSetRestart() have to be
>    completely in header files or in the libpetscksp.dylib and this
>    would require moving lots of stuff around. Putting
>    KSPGMRESSetRestart() in the base library and the GMRES in the
>    plugin library is also kind of silly since KSPGMRESSetRestart() is
>    specific to GMRES and really doesn't belong in the base
>    library. 

Yes, the user that doesn't want to *depend* on the impl library that
defined KSPGMRESSetRestart would have to dlsym it and call through the
function pointer.  This is why I think they will generally raise the
dlopen/dlsym level to the app-specific plugin that probably has a
narrower interface.

>    The reason the PetscInitialize_DynamicLibraries() is called in
>    PetscInitialize() instead of delayed until needed is if dynamic
>    loading required some collective MPI action rather than something
>    each MPI process can do completely asynchronously. Of course we
>    have no experience with that case.

Is this a real scenario?  The caller needed to open the library in order
to call it.  Meanwhile, XXInitializePackage is no longer collective
(discussed back in February) and if was, it would be an issue with
normal static or shared libraries.  Note that the same dlopen code is
called before main when you use shared libraries as is called when your
application dlopens a library later.

>    I would say we currently don't really have a use for the
>    --with-dynamic-loading it is just a stand in for future
>    possibilities :-)
>
>    We could drop the configure option and add a runtime option
>    -dynamic_loading that triggered the loads in PetscInitialize()

If it's useful, I'd rather do it that way.  Configure-time options are
evil.

>     We could also just leave things as they are and say "why are you
>     building things using --with-dynamic-libraries? there is nothing
>     to be gained"

I.e., place traps for naive users?

> Also, given that the first line of KSPInitializePackage is:
>  if (KSPPackageInitialized) PetscFunctionReturn(0); and
> PetscDLLibraryRegister_petscksp has already called
> KSPInitializePackage, isn't the preprocessor guard redundant?
>
>    Yes, I think the guard is now redundant and could be removed. This
>    stuff evolved over time without ever having a really strong case
>    for dynamic libraries except future possibilities.

Okay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130829/6c0b16a6/attachment.sig>