dolfin team mailing list archive

[Joachim Haga <jobh@xxxxxxxxx>]

I thought some about the destruction order problem overnight. The
current construct is safe as long as no external static destructor calls
methods on the singleton. This cannot be enforced at compile-time (as
far as I know), but a big warning comment may work.

Furthermore: It is possible to make the failure-case error early at
runtime, something like:

static bool singleton_is_alive;

SSM::SSM() {
...
singleton_is_alive = true;
}

SSM::~SSM() {
...
singleton_is_alive = false;
}

singleton() {
...
assert(singleton_is_alive);
return ...
}

Finally: The state of the destructed singleton is undefined in principle
(probably -- haven't checked the standard), but in practice it is known.
It is just the object after its destructor has been run -- I don't think
any compiler would emit code to actually overwrite the memory. This is
in contrast with the un-initialised singleton that was the original
problem. So maybe this assert() can be inserted into only those methods
that would fail in this state.

-- 
You received this bug notification because you are a member of DOLFIN
Team, which is subscribed to DOLFIN.
https://bugs.launchpad.net/bugs/726484

Title:
  mpi_init is sometimes called on uninitialised object

Status in DOLFIN:
  Confirmed

Bug description:
  Due to undefined order of initialisation of static objects,
  SubSystemsManager::init_mpi is sometimes called before the
  constructor. The visible effect is (at least in my case) that
  MPI_Finalize is never called.

  Patch attached.