<div dir="ltr">In [1], PetscFunctionListAdd became implicitly collective on COMM_WORLD, but the all the XXRegisterDynamic() say "Not collective". These all have to be updated if this is the case, but I'm not sure it's even a good thing. What if we have a big multi-domain simulation in which we initialize each of the components on their own subcomm. Those sub-components would not be allowed to register methods (or load plugins) that they might use because registration was implicitly more global.<div>
<br></div><div style>The comm is used by PetscLs and others. This is important because file systems are terrible at independent access. (Same for loading shared libraries; it's potentially much easier to do it by broadcasting the library, though portability is tricky.)</div>
<div style><br></div><div style>Anyway, it would be really bad to PetscDLLibraryAppend() on a subcomm and have the registration function in the shared lib call PCRegisterDynamic() that promotes itself to COMM_WORLD.</div>
<div style><br></div><div style>Maybe we need to pass an explicit comm to all the registration functions.</div><div style><br></div><div style>[1] <a href="https://bitbucket.org/petsc/petsc-dev/commits/07f9e01e040feeb4162253a60ca63556436f4135">https://bitbucket.org/petsc/petsc-dev/commits/07f9e01e040feeb4162253a60ca63556436f4135</a><br>
<br>What does "Formally collective" mean anyway? Either it's always safe to call independently, it's "Logically collective" so that there is no performance impact, but it still needs to be collective to have consistent state, or it's Not Collective. This falls under Not Collective because it can deadlock if you call it independently.</div>
</div>