Date: Thu, 4 Jan 2001 00:19:43 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Kirk McKusick <mckusick@mckusick.com> Cc: Will Andrews <will@physics.purdue.edu>, Peter Wemm <peter@netplex.com.au>, Stephen McKay <mckay@thehub.com.au>, phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010104001943.T292@fw.wintelcom.net> In-Reply-To: <200101040719.XAA04872@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jan 03, 2001 at 11:19:02PM -0800 References: <20010103124110.L86630@argon.firepipe.net> <200101040719.XAA04872@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kirk McKusick <mckusick@mckusick.com> [010103 23:19] wrote: > > As the original author of <sys/queue.h> I would like to speak up > in support of the removal of CIRCLEQ. They were originally added > because I had not thought up a portable way to traverse TAILQ's > in reverse and certain applications need that functionality. A > few years ago, when reviewing the TAILQ functions, I realized that > it is in fact possible to traverse TAILQ's in reverse in a portable > way and added the TAILQ_PREV function. With this addition, there > were no capabilities left in CIRCLEQ that could not be done with > TAILQ in a more efficient manner (TAILQ's generate fewer tests > when doing their operations than CIRCLEQ's). Further, the termination > conditions for TAILQ's (testing against NULL) are much simpler and > more easily coded than the termination condition for CIRCLEQ's > (saving the queue head and checking to see if it has been reached). > CIRCLEQ's have been very lightly used, and few users will be > inconvenienced by their removal. The resulting code base will be > simpler, faster, and cleaner. There are times when one should > break with the past, and I believe that this is just such a time. *blush* You're right, I'm wondering though, would it be possible to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, field) by using the offset of 'field' into the struct? You could subtract the offset of 'field' from the tqe_prev of the next struct right? This would also reduce it by one memory access. Or is this the unportability/headache you were trying to avoid? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010104001943.T292>