Re: weak pointers, cbdata, refcounting

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Mon, 22 Aug 2005 22:07:56 -0600 (MDT)

On Tue, 23 Aug 2005, Robert Collins wrote:

> On Mon, 2005-08-22 at 16:38 -0600, Alex Rousskov wrote:
>> Hi there,
>>
>> I need to implement what some call a "weak pointer". A weak pointer
>> becomes null or otherwise invalid when the corresponding object goes
>> away or is invalidated. For an example, please see
>>
>> http://www.boost.org/libs/smart_ptr/smart_ptr.htm
>>
>> I cannot use existing RefCount.h for weak pointing because the interface
>> does not support "invalidation" of a pointer -- the RefCount pointer
>> stays valid until nobody uses it.
>
> CBData works fine with standard classes.

Hi Robert,

         That's good to know! Apparently, I do not use cbdata correctly
because it does not seem to work for me. Could you please point me to
the updated (with respect to classes) cbdata docs or notes? Perhaps I
just need to add more #define-driven glue to base (or all?) classes...

If there are no docs or notes, what should I add to A, B, C, and ABC
classes in my original question so that:

         (a) cbdata operations on A, B, C, or ABC pointer would be
noticeable when working with pointers of the other three types, and

         (b) all four destructors are called when the last reference is
gone via a cbdata operations on A, B, C, or ABC pointer?

> I'm curious though why you need a weak ref? Most weak ref uses I've
> seen are roughly a failure to use observers.

I am not sure I follow. Is not a weak pointer an example of an
observer?

I agree that I can implement other kinds of observers that would be
"more explicitly" notified when the original object is invalidated,
but having a simple and generic weak pointer seems like a more
straightforward and a "standard" solution than a custom
subscribe/publish interface.

I am not sure I can explain why I want a weak pointer in a short
email, but I will try. I have a MsgPipe class that asynchronously (via
Squid's events) forwards "messages" from the Source object to the Sink
object. MsgPipe needs to ignore the pending message when the Sink is
gone/invalidated. MsgPipe does not know the final type of the Sink,
and several classes inherit from the Sink abstract interface (i.e.,
many types can be used as sinks). Ideally, a sink would not have to
maintain a list of pipes that are using it (so that it can inform them
that it is gone).

Thanks,

Alex.
P.S. MsgPipe.h and friends are in the squid3-icap branch.
Received on Mon Aug 22 2005 - 22:08:06 MDT

This archive was generated by hypermail pre-2.1.9 : Wed Aug 31 2005 - 12:00:06 MDT