possible new problem: dynlibs retrieved twice, need advice for fix
Barry Smith
bsmith at mcs.anl.gov
Tue Oct 21 13:59:08 CDT 2008
Lisandro,
I've briefly reviewed the code to refresh my memory on how it
work. Here is
my interpretation of the present structure.
Public interface
PetscDLLibraryAppend() and Prepend()
PetscDLLibrarySym()
PetscDLLibraryClose()
"Private" interface
PetscDLLibraryOpen() (note that this is not really the
opposite of PetscDLLibraryClose()
PetscDLLibraryRetrieve()
These are intended as THE replacement to dlopen(), dlsym(), dlclose().
Hence having
a PetscDLOpen(), PetscDLSym(), PetscDLClose() would be redundant. You
know I hate
to have two different ways to do the same thing.
_n_PetscDLLibrary is then a REPLACEMENT for the void** handle you get
from dlopen(),
but it has the additional functionality that several handles can be
kept and used together.
PetscDLLibraryAppend() and Prepend() are then THE replacement for
dlopen() and
PetscDLLibrarySym() is THE replacement for dlsym().
PetscDLLibrarySym() is a replacement for dlsym() with the flexibility
to find a symbol is
several handles/files and to look in a particular file for the symbol.
The idea is Unix paths,
when I run cc it looks for cc in that path and when I run /bin/cc I
tell it which particular one
to use.
The ALL have the IMPORTANT dependence on a MPI_Comm, that dlopen(),...
do not.
This is all independent of whether one is using PETSc dynamic
libraries or not , except I
have the single PETSC_HAVE_DYNAMIC flag that turns everything on. The
entire dl.c
file should be TURNED on if the PETSC_HAVE_DYNAMIC flag is on.
Traditional dlopen(), dlsym() dlclose() can be emulated with the above
using
PetscDLLibrary *library = PETSC_NULL
PetscDLLibraryAppend(.... &library,filename)
PetscDLLibrarySym(....library, symbolname)
PetscDLLibrarySym on other symbols
PetscDLLibraryClose(library)
----------------------------------------------------------------------------------------------------------------------
Now for PETSc's dynamic libraries, PETSc maintains A _n_PetscDLLibrary
object for managing ITS dynamic libraries.
this is handled through the PetscLoadDynamicLibrary() interface. This
interface should
be turned on ONLY if PETSC_USE_DYNAMIC libraries is turned on.
--------------------------------------------------------------------------------------------------------------------
My question to you is then: what changes/additions/fixes do we need to
add to the
PetscDLLibraryAppend() and Prepend() PetscDLLibrarySym()
PetscDLLibraryClose()
public interface so that it may be used for all of your needs???? Ok,
the current interface
may be a little clumsy, let's make it less clumsy rather than adding a
whole new PetscDLOpen()...
interface next to it that has the same functionality. I'm even fine
with changing names and adding
new methods to the current interface.
Barry
On Oct 21, 2008, at 10:04 AM, Lisandro Dalcin wrote:
> Barry, I catched a new problem. At PetscInitialize(), dynamic
> libraries are 'retrieved' twice. The calls that leads to this are the
> following:
>
> PetscInitialize()
> PetscInitialize_DynamicLibraries()
> PetscLoadDynamicLibrary() // helper routine for opening each
> libpescXXX lib
> PetscDLLibraryRetrieve() // FIRST call
> PetscDLLibraryAppend()
> PetscDLLibraryOpen()
> PetscDLLibraryRetrieve() // SECOND call
That first use of Retrieve() is probably not needed and should be
removed.
>
>
> However, I'm not sure if this is a real issue. It seems that
> ./bin/urlget.py is smart enough as to skip downloading based on
> timestamps (though I'm not sure if the same applies to the wget
> fallback in 'bin/urlget' shell script)
>
>
> --
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>
More information about the petsc-dev
mailing list