Re: additional queue macro

2002-07-04 Thread Daniel Eischen
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

Re: additional queue macro

2002-07-04 Thread Julian Elischer
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

Re: additional queue macro

2002-07-04 Thread Daniel Eischen
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

Re: additional queue macro

2002-07-04 Thread Julian Elischer
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

Re: additional queue macro

2002-07-04 Thread Daniel Eischen
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

Re: additional queue macro

2002-07-04 Thread Julian Elischer
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

Re: additional queue macro

2002-07-04 Thread Daniel Eischen
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

Re: additional queue macro

2002-07-03 Thread Bruce Evans
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.

Re: additional queue macro

2002-07-03 Thread Terry Lambert
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

Re: additional queue macro

2002-07-03 Thread Garance A Drosihn
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 --

Re: additional queue macro

2002-07-03 Thread Julian Elischer
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

Re: additional queue macro

2002-07-03 Thread Neal Fachan
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 temporary variable. On Tue, Jul 02, 2002 at

Re: additional queue macro

2002-07-02 Thread W Gerald Hicks
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

Re: additional queue macro

2002-07-02 Thread Ian Dowse
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

Re: additional queue macro

2002-07-02 Thread Julian Elischer
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)

Re: additional queue macro

2002-07-02 Thread Jonathan Lemon
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,

Re: additional queue macro

2002-07-02 Thread Julian Elischer
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) =

Re: additional queue macro

2002-07-02 Thread Terry Lambert
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

Re: additional queue macro

2002-07-02 Thread Julian Elischer
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

Re: additional queue macro

2002-07-02 Thread Garrett Wollman
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

Re: additional queue macro

2002-07-02 Thread Julian Elischer
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

Re: additional queue macro

2002-07-02 Thread Julian Elischer
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,

Re: additional queue macro

2002-07-02 Thread Terry Lambert
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

Re: additional queue macro

2002-07-02 Thread Terry Lambert
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

Re: additional queue macro

2002-07-02 Thread Julian Elischer
I might add that phk added the itterators in 1.14, but since he's off getting married we can't ask him whether he thinks the 'safe' versions are OK.. Yeehaaa open season.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message