<div class="gmail_quote">On Thu, Jul 19, 2012 at 2:07 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb adM"><div class="im">> I agree, but I could not find an easy way.<br>
<br>
</div></div>  Can you find a difficult way ?<br>
<br>
  We chose to make the DM both a factory for creating stuff and a place to stash stuff that people can pull out later, this will lead to more and more of these loops. We could<br>
<br>
1) do proper garbage collection always (yuck from the person who has to write that perspective)<br></blockquote><div><br></div><div>Due to the need for deterministic destruction in parallel, I think this ends up more-or-less requiring eager loop-breaking, which means we have to either (a) keep two-way links so that parents can have ref-count information updated upon composition or (b) full dependency graph traversal on each dereference.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) have separate factories that the user manage; so basically split the DM into two parts that do not reference each other. (Yuck from the user perspective)<br>
<br>
3) continue with all these hacks to prevent loops<br></blockquote><div><br></div><div>I think loops are only needed in special cases. We haven't needed them until now. If we change DM to keep upward and downward links (nice for some cases of FMG), those would also have the same concern. We could make a PetscObjectComposeTwoWay() that created, and enforced two-way links. I'd prefer not to allow arbitrary loops.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) something else?</blockquote></div><br>