Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@samba-tng.org>
To: "Greg Stein" <gstein@lyra.org>
Cc: <dev@apr.apache.org>
Subject: RE: cvs commit: apr/memory/unix apr_sms.c apr_sms_std.c
 apr_sms_tracking.c
Date: Fri, 8 Jun 2001 12:22:49 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOCENDDPAA.striker@samba-tng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010608030925.L23560@lyra.org>
Importance: Normal

[..]
> > Yes, but you are missing something here. You would have to create
> > a list header to nest in the apr_sms_t structure. With the ref
> > concept you don't need that, because it can point to parent->child.
>
> I'm not sure that I follow. We have a complete set of
> navigational pointers:
> parent, child, prev, next. With those, I'm not sure what you mean
> by a "list
> header".
>
> Insertion as a child of "this" is:
>
>     new->parent = this;
>     new->next = this->child;
>     if (new->next != NULL)
>         new->next->prev = new;
>     this->child = new;
>
> Removal is:
>
>     if (this->prev != NULL)
>         this->prev->next = this->next;
>     if (this->next != NULL)
>         this->next->prev = this->prev;
>     if (parent->child == this)
>         parent->child = this->next;
>
> Is it that you are you saying that the third condition of the removal is
> unnecessary with the "ref" scheme?

Yes, that's exactly what I'm saying.

> > And although for removing from a list it is almost the same
> > number of operations, for inserting into a list you have more.
> > Anyhow, same idea, different approach.
>
> If you don't mind, could you elaborate? I'm confused on what you
> mean here.

Since we are always inserting at the head of the list it has less
of an impact. Didn't occur to me before, but does now.

> > Since the only place this
> > is used is inside the sms framework code could we please leave it
> > be for now? I'd like to focus on some other stuff first :-)
>
> You can focus on whatever you'd like. While you're doing that, we'll sneak
> in and change the names, make tweaks to the code, etc. Remember: the code
> can be attacked by more than one person :-)

Ack. I know that. There are multiple people working on sms actually :-)
Go ahead on the name change. I think noone likes extra typing :-)

Sander