[petsc-dev] threadcomm memory leak

[Jed Brown]

On Mon, Jul 16, 2012 at 6:53 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>    Yes, that is absolutely a hack and does not belong there. But you are
> totally miss understanding what I am saying: that hack is NEW. For 15 years
> PETSc did NOT need a hack to work with MPIUNI (which has a single
> communicator), thus I conclude that MPUNI is fine and something is wrong
> with the PETSc thread comm stuff if it requires that hack. That is, why the
> heck does petscthreadcomm depend on MPI_COMM_SELF != MPI_COMM_WORLD while
> for 20 years NOTHING ELSE IN PETSc (which is a dang lot more complicated
> than petscthreadcomm) does not depend on MPI_COMM_SELF != MPI_COMM_WORLD???
>

As far as I know, the other calls to MPI_Attr_put occur the first time the
comm is used with an object rather than being pre-initialized. In this
case, PETSC_COMM_SELF and PETSC_COMM_WORLD are pre-endowed with the
threadcomm. Should the threadcomm be placed in some global variable and
obtained (and referenced) the first time it is used with a given
communicator? If we store the canonical one on a comm, then it must be on
COMM_WORLD and COMM_SELF.


>
>    In other words fix petscthreadcomm model; don't mess with a perfectly
> good mpiuni.
>

MPI has them as separate communicators. MPIUNI breaks that model for, as
far as I can tell, no good reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120716/a62a7e48/attachment.html>