Robert Collins wrote:
> Yes, but. IMO it makes more sense to use refcounted data. The problem
> with cbdata is that during reconfigure, any long lived process that is
> configuration dependent gets trashed. ACL's are one example. Peers also.
> (what happens when we are half way through getting a list of potential
> upstreams and the peer we _just selected_ is made invalid.
Nothing really except that cbdataValid() turns false. The peer data is
still valid until your reference goes away. Atleast in theory if cbdata
is implemented properly for peer structures.
Same thing as reference counted allocation, except that we know that the
allocation is stale. Since it is stale we know that addressing ->next is
not a good idea unless we have that one locked as well.
> Configuration data isn't a callback (you now when it becomes valid
> and when its no longer needed), but more a reference you know how
> many users there are and when that hits 0 you free it (and the parser
> tree has a reference to prevent it dropping below 0).
For many things it is also good to know that the reference is stale, for
example a peer. Not all operations on the peer is valid if it is not the
current configuration entry for that peer.
> In summary refcounting and cbdata are nearly identical, the difference
> being that refcounting allows use after the "config entry" is
> reconfigured away, whereas cbdata doesn't (cbdataValid will fail).
true.
cbdata allows references, only difference is that it also allows you to
tell that the reference points to data that has been requested to be
freed.
About the only type of allocations where cbdata is NOT suitable is when
you do not have a main reference, but all your references to the
allocation are identical (for example a I/O buffer shared between
multiple "threads")
The other type of allocations is when there will never be any other
references to the data except for the main references (i.e. properly
encapsulated data). cbdata can still be used, but a mempool is a better
choice then.
-- HenrikReceived on Sun May 13 2001 - 04:24:05 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:01 MST