I guess this begs the question: how does a library detect that the shmem region has already been mapped? If we attempt to map it and fail, does that mean it has already been mapped or that it doesn't exist?
It isn't reasonable to expect that all the libraries in a process will coordinate such that they "know" hwloc has been initialized by the main program, for example. So how do they determine that the topology is present, and how do they gain access to it? > On Feb 3, 2021, at 6:07 AM, Brice Goglin via devel <devel@lists.open-mpi.org> > wrote: > > Hello Ralph > > One thing that isn't clear in this document : the hwloc shmem region may > only be mapped *once* per process (because the mmap address is always > the same). Hence, if a library calls adopt() in the process, others will > fail. This applies to the 2nd and 3rd case in "Accessing the HWLOC > topology tree from clients". > > For the 3rd case where low-level libraries don't want to depend on PMIx, > storing the pointer to the topology in an environment variable might be > a (ugly) solution. > > By the way, you may want to specify somewhere that all these libraries > using the topology pointer in the process must use the same hwloc > version (e.g. not 2.0 vs 2.4). shmem_adopt() verifies that the exported > and importer are compatible. But passing the topology pointer doesn't > provide any way to verify that the caller doesn't use its own > incompatible embedded hwloc. > > Brice > > > Le 02/02/2021 à 18:32, Ralph Castain via devel a écrit : >> Hi folks >> >> Per today's telecon, here is a link to a description of the HWLOC >> duplication issue for many-core environments and methods by which you >> can mitigate the impact. >> >> https://openpmix.github.io/support/faq/avoid-hwloc-dup >> <https://openpmix.github.io/support/faq/avoid-hwloc-dup> >> >> George: for lower-level libs like treematch or HAN, you might want to >> look at the envar method (described about half-way down the page) to >> avoid directly linking those libraries against PMIx. That wouldn't be >> a problem while inside OMPI, but could be an issue if people want to >> use them in a non-PMIx environment. >> >> Ralph >> >
