Several people have asked what the heck this function is for. It's
there to make it easier to satisfy object ownership rules.
For example, suppose you open an svn_fs_root_t ROOT in some pool
ROOT-POOL. Then you call open_path on ROOT in some trail PATH-TRAIL,
which builds you a parent path PATH. The top (last) element of PATH
must be a dag_node_t DAG referring to the same root directory as ROOT.
There are two ways to do this:
- You could have PATH just refer to ROOT's dag_node_t. But then you'd
better hope that PATH-TRAIL's pool is freed before ROOT-POOL;
otherwise, PATH will end up with a dangling pointer to a freed
dag_node_t.
- You could dup ROOT's dag_node_t into PATH-TRAIL's pool, and now you
don't have to worry about the relative lifetimes of ROOT-POOL and
PATH-TRAIL.
In other words, svn_fs__dag_dup helps open_path satisfy the rule that
no object in a pool P1 may point to any object in a pool P2 unless you
know that P1 will be freed before P2 --- say, because P1 is a child of
P2.
This is a common problem in memory allocation disciplines based on
explicit freeing: modules are restricted in what they can do with
objects they're passed in, because they don't know their lifetimes.
You can declare it the caller's responsibility to ensure the lifetimes
work out, but this can reveal details of your implementation, and it
may not be any easier for the caller to guarantee the lifetimes. But
if you can copy the object, you don't need to bother the caller at
all.
Reference counting is another way to get around the problem.
Received on Sat Oct 21 14:36:23 2006