From owner-freebsd-arch Wed Jan 3 23:19:22 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 23:19:20 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id D3E5637B400; Wed, 3 Jan 2001 23:19:19 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id XAA04872; Wed, 3 Jan 2001 23:19:02 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101040719.XAA04872@beastie.mckusick.com> To: Will Andrews Subject: Re: Reinstatement of CIRCLEQ Cc: Peter Wemm , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: Your message of "Wed, 03 Jan 2001 12:41:10 EST." <20010103124110.L86630@argon.firepipe.net> Date: Wed, 03 Jan 2001 23:19:02 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Wed, 3 Jan 2001 12:41:10 -0500 From: Will Andrews To: Peter Wemm Cc: Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ [ moved to -arch since this is really the correct location for it ] On Wed, Jan 03, 2001 at 09:24:17AM -0800, Peter Wemm wrote: > > Put your complaints about CIRCLEQ in the manual page, and people > > can choose based on facts. All this commit does is reduce code > > portability. > > I tend to agree, for what it is worth. CIRCLEQ() is an expected > part of the 4.4BSD API and an expected part of . > We dont have to use it, but I feel it is a mistake to nuke an > API that is expected to be there. I've never read Knuth's book and am not particularly knowledgeable about queue(3). But I think that unless a good reason (which I have not seen yet) is given for why CIRCLEQ() was nuked, it should be put back. Especially since there doesn't seem to be any kind of move like this in the NetBSD or OpenBSD camps. So this might end up biting FreeBSD in the ass someday as far as portability goes. So, why remove CIRCLEQ()? -- wca As the original author of 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. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message