Date: Thu, 3 Jan 2002 17:53:35 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Julian Elischer <julian@elischer.org>, Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Stephen McKay <mckay@thehub.com.au>, John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Greg Lehey <grog@FreeBSD.org> Subject: Re: cvs commit: src/share/man/man3 queue.3 Message-ID: <p05101005b85a8a34d794@[128.113.24.47]> In-Reply-To: <Pine.BSF.4.21.0201031358340.24204-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0201031358340.24204-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101005b85a8a34d794>