From owner-freebsd-current Tue Jul 2 14: 9: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77EA237B8D4 for ; Tue, 2 Jul 2002 14:07:23 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4631D44E23 for ; Tue, 2 Jul 2002 14:00:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702210023.FGLO29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Tue, 2 Jul 2002 21:00:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA98116; Tue, 2 Jul 2002 13:47:23 -0700 (PDT) Date: Tue, 2 Jul 2002 13:47:22 -0700 (PDT) From: Julian Elischer To: Jonathan Lemon Cc: current@freebsd.org Subject: Re: additional queue macro In-Reply-To: <20020702153446.A66367@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 2 Jul 2002, Jonathan Lemon wrote: > On Tue, Jul 02, 2002 at 12:58:24PM -0700, Julian Elischer wrote: > > > > On Tue, 2 Jul 2002, Jonathan Lemon wrote: > > > > > What do people think about adding the following macro to ? > > > (I don't care much about the name, just the functionality) > > > > > > #define TAILQ_FOREACH_TMP(var, tmp, head, field) \ > > > for ((var) = TAILQ_FIRST((head)); \ > > > (var) && (((tmp) = TAILQ_NEXT((var), field)) || 1); \ > > > (var) = (tmp)) > > > > Certainly this is moving in the right direction.. > > (acknowleging the problem).. It does the job. > > but if someone knows to use it then they probably also > > know to use a temp variable themselves. > > > > It does work in that there is very little the writer can do to screw this > > up. > > > > The question is simply "is it waranted?" > > It does add complexity.. I guess it needs to be added to all > > the other types as well (LIST, STAILQ etc) > > Well, as Garrett pointed out, the question also is, "is this correct?" > It appears that the old behavior of not modifying the list pointer may > actually be part of the API (although undocumented), and one way to fix > the problem is to just document the behavior. > > Since user programs (like libc_r) may already depend on this, perhaps > the most prudent choice may be to leave the original behavior alone. yes. though the -1s in the kernel showed several bugs where threads were being handled as if they were on a list when they were no longer on that list. I'll leave it as part of teh debug code.. which brings up another question, Do you think I should remove the debug stuff when KSE becomes stable? Or maybe extend it to the other types. It was very useful in debugging KSE, showing the last 2 places that touched the linkages, but it may obscure teh source too much. thoughts anyone? > -- > Jonathan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message