I'll look at that, maybe on weekend. The first very short try failed, I
realized for falcon it would not be overly simple.
The reason is that.
Unlike STL for example, Falcon does not use specialized "container" classes,
that can store anything.
Every Falcon object that can potentially live in a list has a member named
"next" . Objects that can live in 2 lists, have 2 next pointers (like
DeferredIndex has "next" and "nextInTransaction" pointers). Placing object
into a list is often accomplished via object->next = head. This operation
is not a copy and does not increment reference counter magically. I conclude
that automatic reference counting suck on self-backed linked structures.
Yet, Falcon has at least one class, that resembles STL container a bit. It
is DenseArray. I'll continue my experimentation with it.
PS: Looks like an addition to Commandments of Manual RefCounting : increment
the refcount when placing object into a list, and decrement when removing
from a list.
> -----Original Message-----
> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
> Sent: Monday, October 06, 2008 11:41 PM
> To: Vladislav Vaintroub
> Cc: falcon@stripped
> Subject: Re: Understanding RefCounts in Falcon
> >Vladislav Vaintroub wrote:
> > a) string tmp = object1->object2->object3->str; //copy constructor
> > b) string &tmp = object1->object2->object3->str; //no copy, tmp
> > changed
> > c) const string &tmp = object1->object2->object3->str; // no copy,
> tmp is
> > immutable
> > In case b) and c) no copy is involved.
> > I believe there are basically 3 cases where copies can be created:
> > 1) passing via function parameter -> copy/increment can and must be
> > 2) tmp copy inside a function -> copy/increment can and must be
> > 3) passing object to the constructor of another object ->
> copy/increment may
> > be done. Depends on lifecycle of another object, if it can outlive
> > object - copy necessary , if not, copy not necessary.
> > 4) reading object from containers (list/queue) shared between threads
> > copy/increment must be done
> > Can you think of something else?.
> Both 3 and 4 involve holding a pointer to an object for longer periods
> of time. And you seem to think that the code could be designed with
> smart pointers so that the unnecessary increments can be avoided. I
> would love to see an example of that.
> I think the DeferredIndex objects are a great place to start. The long
> term locations for pointers to a DI object are;
> Index:: Queue<DeferredIndex> deferredIndexes;
> Transaction:: DeferredIndex *deferredIndex;
> DeferredIndexWalker:: DeferredIndex *deferredIndex;
> WalkDeferred:: DeferredIndex *deferredIndex;
> Currently the Index::deferredIndexes location is not being refcounted.
> Chris and I think it probably should, but no bugs indicate the need for
> it. The transaction is the primary owner and the code is prepared,
> after Bug#39846, for the index to go away sooner than the transaction.
> Anyway, that would be a great place to propose a smart pointer solution
> for us to evaluate. If it has the same number of interlocked
> and decrements as the current code, then it should be more stable and
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1