1. 6
  1.  

  2. 2

    Without knowing the particulars, I’d generally say that using a shared flag as a fake refcount is an anti pattern. Sooner or later, the object is shared twice, the first share is dropped (clearing the flag), and then boom. This is akin to a buggy read/write lock that completely unlocks after the first reader releases it.

    1. 1

      I don’t know if I’d call the flag a refcount; it’s more of a “do I own this piece of data”, so there’s no clearing that flag. I was able to determine that the owner of the callsite always outlives borrowers, so it’s safe to clean up the data if the owner is being collected.

      1. 1

        That’s how it starts. :) Then the borrower starts to live just a little bit longer and oops. And it’s hard to assert that this doesn’t happen. The owner can’t check that the flag is cleared when it cleans up because the borrower can’t clear the flag.

        1. 1

          Maybe you’re right, but keep in mind that subsignatures are kind of like child nodes in a tree. If you have a tree structure where each node can point to a chunk of memory it owns, or to a chunk of memory owned by any ancestor of that node, that ownership flag should suffice as long as you clean up the tree from the leaves up, right?