From owner-cvs-all Thu Jan 3 14:54: 1 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4A3B337B405; Thu, 3 Jan 2002 14:53:48 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g03MrbC73084; Thu, 3 Jan 2002 17:53:37 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Thu, 3 Jan 2002 17:53:35 -0500 To: Julian Elischer , Matthew Dillon From: Garance A Drosihn Subject: Re: cvs commit: src/share/man/man3 queue.3 Cc: Poul-Henning Kamp , Stephen McKay , John Baldwin , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Greg Lehey Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.1 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:00 PM -0800 1/3/02, Julian Elischer wrote: >On Thu, 3 Jan 2002, Matthew Dillon wrote: > >> : >> :I don't understand your point.. >> :TAILQ_FIRST() does not do a conditional to give a NULL on empty.. >> :...#define TAILQ_FIRST(head) ((head)->tqh_first) >> >> My example wasn't meant to be compatible with sys/queue.h, but if you >> look at sys/queue.h you will find that CIRCLEQ_FIRST() does not >> return NULL on an empty list, nor does CIRCLEQ_NEXT(). You have >> to use CIRCLEQ_EMPTY() to test for an empty lilst and you pretty >> much have to use CIRCLEQ_FOREACH() to iterate over a list. > >So what.? >We are arguing about TAILQ_FOREACH not CIRCLEQ_FOREACH (Which phk >deleted anyhow) I think you're so focused on "improving" TAILQ that you're missing what I consider an important design goal of these macros. The idea, as I understand it, is that a person could say "I want a tail-queue for this data-structure", and use the TAILQ_* macros. Later, when someone invents COOLERTHANTAILQ, a programmer could say "Given the real-world characteristics of my information, this cooler-than-tailq data structure will result in better {performance|memoryUsage|tasting-wine}. So, I will use this new form of queue, and the *only* thing I have to do is add the 'cooltail' variable to the struct I am using, and then change all TAILQ_* macros to COOLERTHANTAILQ_* macros. Done". You are proposing that developers should both know and take advantage of characteristics of one specific kind of queue. As such, one can not just change the "type of queue", they also have to check every place that manipulates that queue to see if the code is using "special and unique knowledge" of the type of queue. Instead of documenting that "TAILQ_FOREACH" has one behavior, and that other queue-types will not have that behavior, we should document that the behavior IS NOT DEFINED and SHOULD NOT BE COUNTED ON in any code for any type of queue. What the behavior happens to be for any particular style of queue is not relevant, the question is what behaviors should be counted on when writing code. Step back for a minute and just think about this. You've got Matt, PHK, and me all agreeing that these *_QUEUE macros should be generic. You would think that you should be able to convince at least ONE of us to agree with you, given that we are more than happy to disagree with each other when the occasion warrants. You have tried to explain your case several times now, and I completely understand the point you're making. However, I still disagree with it, because what you are hoping to do will go against the main objective of having a "queue.h" set of macros. Any thing which is supposed to be true for one set, *is* supposed to be true for all (in the sense of how the programmer should use them). Yes, you'll save 1.3 milliseconds by not wasting your time with a dummy variable (such as I suggested in my previous message), but that is not the point of these macros. It's "queue.h", not "optimizeTailq.h". Discussions on TAILQ_* *are* related to any of the other BLAHQ_* macros in that include file. At least, that is my impression of that include file. I'm sure someone will muster up the courage to correct me if I'm wrong... :-) And I won't mind being corrected, if I do have the wrong idea here. Perhaps another way to address this is to provide another set of BLAHQ_* macros, which would do exactly what you want (with the absolute optimal performance characteristics for TAILQ), but write one for each kind of queue. That way, people could change TAILQ_DIDNT_DO_EACH() to COOLERQ_DIDNT_DO_EACH(), and if there was no such macro then they'd have a very large flag telling them to look closer at that section of code. The problem with your suggestion, as it stands right now, is that you are writing code which is specific to one kind of queue, but you are not "hiding" that in a BLAHQ_* macro. While this solution would work for me, I'll admit that I haven't the slightest idea of a good name for that macro... In any case, we are not disagreeing with you just to irritate you, or because we don't understand what you are hoping to do. We just think you're breaking a useful abstraction of "queues" (generic queues, not tailq-specific queues), and that you should not do that. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message