On Wed, 3 Jul 2002, Julian Elischer wrote:
On Wed, 3 Jul 2002, Neal Fachan wrote:
We've got local changes (which I've attached) where the name is
*_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the
temp variable is the second argument. I can't think of a way of doing
that was teh plan... we're just discussing the name..
TAILQ_FOREACH_SAFE ?
On Thu, 4 Jul 2002, Daniel Eischen wrote:
On Wed, 3 Jul 2002, Julian Elischer wrote:
On Wed, 3 Jul 2002, Neal Fachan wrote:
We've got local changes (which I've attached) where the name is
*_FOREACH_REMOVE. We
On Thu, 4 Jul 2002, Julian Elischer wrote:
that was teh plan... we're just discussing the name..
TAILQ_FOREACH_SAFE ?
Oh, I thought the initial proposal was to add a _new_ interface
that allowed safe removals while traversing the list (and allow
the existing macros to be changed for debugging
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)
2/
We could add a new macro/method that is slightly less efficient
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
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
On Thu, 4 Jul 2002, Julian Elischer wrote:
On Thu, 4 Jul 2002, Daniel Eischen wrote:
On Thu, 4 Jul 2002, Julian Elischer wrote:
2/
We could add a new macro/method that is slightly less efficient than the
current FOREACH macros, but allows element removal.
Exisiting methods
On Tue, 2 Jul 2002, Ian Dowse wrote:
In message [EMAIL PROTECTED], Jonathan Lemon writes:
Essentially, this provides a traversal of the tailq that is safe
from element removal, while being simple to drop in to those sections
of the code that need updating, as evidenced in the patch below.
Julian Elischer wrote:
TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE
(I prefer the first) are my suggestions for the name.)
TAILQ_FOREACH_MODIFY ?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
At 10:38 AM -0700 7/3/02, Terry Lambert wrote:
Julian Elischer wrote:
TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE
(I prefer the first) are my suggestions for the name.)
TAILQ_FOREACH_MODIFY ?
I sense great material for a bikeshed... :-)
For mine, how about: TAILQ_FOREACH_VOLATILE
--
On Wed, 3 Jul 2002, Neal Fachan wrote:
We've got local changes (which I've attached) where the name is
*_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the
temp variable is the second argument. I can't think of a way of doing it
without having the externally declare the
On Tuesday, July 2, 2002, at 10:54 AM, Jonathan Lemon wrote:
What do people think about adding the following macro to sys/queue.h?
(I don't care much about the name, just the functionality)
Looks great. How about TAILQ_FOREACH_SAFE?
Thanks, I'm going to put this in our embedded version
In message [EMAIL PROTECTED], Jonathan Lemon writes:
Essentially, this provides a traversal of the tailq that is safe
from element removal, while being simple to drop in to those sections
of the code that need updating, as evidenced in the patch below.
Note that this of course is not safe from
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 sys/queue.h?
(I don't care much about the name, just the functionality)
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 sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head,
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
What do people think about adding the following macro to sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head, field) \
for ((var) =
Garrett Wollman wrote:
On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon [EMAIL PROTECTED] said:
Essentially, this provides a traversal of the tailq that is safe
from element removal, while being simple to drop in to those sections
of the code that need updating, as evidenced in the patch
On Tue, 2 Jul 2002, Terry Lambert wrote:
Garrett Wollman wrote:
On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon [EMAIL PROTECTED] said:
Essentially, this provides a traversal of the tailq that is safe
from element removal, while being simple to drop in to those sections
of the
On Tue, 2 Jul 2002 16:07:36 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said:
I would by the way argue that the statement The queue macros always
guaranteed that traversal was safe in the presence of deletions to be
false. Nowhere was this guaranteed, in fact the Manual page goes to
On Tue, 2 Jul 2002, Garrett Wollman wrote:
On Tue, 2 Jul 2002 16:07:36 -0700 (PDT), Julian Elischer [EMAIL PROTECTED]
said:
I would by the way argue that the statement The queue macros always
guaranteed that traversal was safe in the presence of deletions to be
false. Nowhere was
On Tue, 2 Jul 2002, Julian Elischer wrote:
Having just re-read my own mail
I think I agree with jonathan now..
I think we neeed to either:
1/ augment the man page giving an example of how to do
multiple removes from a list/queue.
2/ Explain in detail why using _FOREACH()
is bad for this,
Julian Elischer wrote:
On Tue, 2 Jul 2002, Terry Lambert wrote:
Garrett Wollman wrote:
[ ... ]
reverted for compatibility with the other implementations of queue(3).
I would by the way argue that the statement The queue macros always
[ ... ]
For the record, Julian is responding to
Julian Elischer wrote:
I would add that there is no occurance I could find in the kernel that
assumes this.. (except the bad one I mentionned before in my own code) (at
least it all runs fine with -1 put in that location on deletion), so I
must not be alone in thinking that one shouldn't rely
23 matches
Mail list logo
