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.
> > > E
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
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 suggesti
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:
> 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
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_
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
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 04:
I agree that it's unfortunately named. The idea was that it's safe to
remove from within the iterator, not that the iterator is doing the
removing...
On Wed, Jul 03, 2002 at 04:04:53PM -0700, Julian Elischer wrote:
>
>
> On Wed, 3 Jul 2002, Neal Fachan wrote:
>
> > We've got local changes (whi
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 th
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_VOLATI
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
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 b
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
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 r
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 resp
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,
On Tue, 2 Jul 2002, Garrett Wollman wrote:
> <
>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
> > lengths to NO
< 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
> lengths to NOT do this..
I'm fairly certain that this *was* documented s
On Tue, 2 Jul 2002, Terry Lambert wrote:
> Garrett Wollman wrote:
> > < 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 below.
Garrett Wollman wrote:
> < 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 below.
>
> The queue macros always guaranteed that traversa
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> What do people think about adding the following macro to ?
> (I don't care much about the name, just the functionality)
>
> #define TAILQ_FOREACH_TMP(var, tmp, head, field) \
> for ((var) = TAILQ_FIRST((head));
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 ?
> > (I don't care much about the name, just the functionality)
> >
> > #define TAILQ_FOREACH_TMP(var, tmp, head, fi
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 ?
> > > (I don't care much about the name, just the functionality)
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
On Tuesday, July 2, 2002, at 10:54 AM, Jonathan Lemon wrote:
> What do people think about adding the following macro to ?
> (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 of queue.h
26 matches
Mail list logo
