On Mar 23, 2013, at 10:47 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> 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".
>
Since we won't be searching through the libraries for symbols we can get
rid of the prepend,append stuff as well and just have a command line option for
opening libraries.
>
>
>
>
>
>> 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.
>
