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 >
