On Jul 19, 2012, at 1:25 PM, Jed Brown wrote:
> On Thu, Jul 19, 2012 at 1:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Why not implement it using PetscObjectQuery()/PetscObjectCompose()? and not
> have to introduce a whole new datatype DMNamedVecLink linked list and other
> crap?
>
> The only reason this thing has to exist, and it really has to exist in some
> form, is that we have a reference loop. For example, the SNES Vec X is
> obtained from the DM (thus X references the DM), but must be made available
> to the KSP callback that uses the DM. If we attached X to the DM, then we
> would have a loop X -> DM -> X. Same for the TS vector needed in
> SNESComputeFunction.
>
> The general form of PetscObjectCompose allowing reference loops is terribly
> dangerous and imprecise (you end up implementing a sort of limited garbage
> collector that periodically looks for loops, but that is super dangerous in
> parallel because you need determinism in destruction).
Is there a way to fix the reference loop problem in PetscObjectCompose()?
(Since you have a magic fix for DMGetNamedGlobalVector() can we use that
everywhere)
You have to admit that introducing in a bunch of places separate constructs
for containment rather than using a single universal construct is not good
software development.
Barry
