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

[Barry Smith]

On Aug 29, 2013, at 10:14 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 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?  

   I don't know.

> 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.