dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Jan 4, 2008 10:43 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> Matthew Knepley wrote:
> > On Jan 4, 2008 10:22 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >> We have a problem at the moment when using PETSc related to conflicts
> >> between dolfin::MPIManager and dolfin::PETScManger as to who should
> >> initialise and finalise MPI. The difficulty is that we can't control the
> >> order in which MPIManager and PETScManager are destroyed.
> >>
> >> Given that we will probably have more 'manager' classes in the future
> >> (e.g. for Trilinos), what is the best approach? Some possibilities are
> >> one 'Manager' class that does the lot, or a SingletonManager which can
> >> control the order in which singleton manager classes are destroyed. Ideas?
> >
> > When using multiple packages with  MPI, you should always have a single MPI
> > manage class. If MPI is already initialized when PETSc is initialized,
> > it won't mess
> > with MPI (and won't finalize it either).
> >
>
> OK. The problem with what I have now is that MPIManager will initialise
> MPI, but might also finalize MPI before PetscFinalize is called. We're
> not calling any finalize functions explicitly, rather from the
> destructor of the manager class.
>
> Perhaps a good approach is to have a Manager class that creates and
> destroys FooManager classes, and is the only class that can create
> FooManager classes.

I guess my opinion is that destructors in languages with automatic memory
management are completely unreliable (and the opinion of the PL community).
I would always have an explicit call for any cleanup which has nonlocal results,
e,g, shutdown of MPI library services.

  Thanks,

    Matt

> Garth
-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener