From owner-freebsd-current Thu Jul 4 12: 0:28 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 D0D8137B400 for ; Thu, 4 Jul 2002 12:00:21 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id D556543E31 for ; Thu, 4 Jul 2002 12:00:20 -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 <20020704190019.JDIF29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 4 Jul 2002 19:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA09335; Thu, 4 Jul 2002 11:40:45 -0700 (PDT) Date: Thu, 4 Jul 2002 11:40:44 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: FreeBSD current users Subject: Re: additional queue macro In-Reply-To: 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 Thu, 4 Jul 2002, Daniel Eischen wrote: > On Thu, 4 Jul 2002, Julian Elischer wrote: > > > there are two proposals floatingat the moment.. > > > > 1/ I added debugging stuff to TAILQ to help find bad usages in KSE. > > Qusetion/proposal: Should I extend this to other types and add it to the > > file (or not delete what is there now) > > I was suggesting that you add macros for debugging purposes instead > of potentially changing existing behaviour. The way you've got it > now is OK I guess, just as long as it somehow doesn't get enabled > or changed in userland. Perhaps it would even break consumers > of it in the kernel, though, too. > > > 2/ > > We could add a new macro/method that is slightly less efficient than the > > current FOREACH macros, but allows element removal. > > Exisiting methods would no change. > > As wollman pointed out, we already assume that it is safe to > remove elements using the existing macros. Adding another > interface to do the same thing kinda imples that existing > behaviour may change. As proposed though, the new macros > would not only allow removals, but also modification of > the removed element while still walking the list. These might > be useful. > In this rare case Garrett was wrong. Only He assumed that. Most people do not assume that, in fact 'folk lore' in general is that it is NOT safe to do that. In fact it is NOT safe to do so if you are going to do anythign WITH that element while still in the loop. The kernel does not do it anywhere I could find, and the man pages specifically avoid doing that. There is no historical precedent because the iterators are already a recent FreeBSD (phk) addition. CSRG did not have them. The ability do do: TAILQ_FOREACH_REMOVABLE(thread, runqueue...) { if (thread should be suspended) { TAILQ_REMOVE(thread); TAILQ_INSERT_TAIL(thread, idlequeue...); } } would be very nice. > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message