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 below.
>
> The queue macros always guaranteed that traversal was safe in the
> presence of deletions. Julian's change is erroneous and should be
> reverted for compatibility with the other implementations of queue(3).
Reverting the change won't guarantee safety. In particular, in the
remove case, the dereference of the "next" pointer in the removed
element is highly dependent on what you do with the removed element.
If you bzero it, then you will have a hell of a time dereferencing
the pointer correctly.
The plan only works correctly where the queue element fields themselves
are type-stable (i.e. they do not get reused to link them onto another
queue, and they do not get reused for other purposes, or zeroed or filled
in with WITNESS or INVARIANTS test values), and if the elements themselves
are allocated out of type-stable memory, as part of maintaining that
guarantee.
The iterator macros are ugly, in that they imply certain semantics,
namely that they will work with the other macros that do element
manipulations. This turns out not to be true, in the delete case.
You could also come up with a failure scenario for tail insertion,
or for head insertion, depending on your assumptions about whether
or not an insertion while in the loop would result in the loop also
doing work on an element, e.g.:
loop
do_work_on_element(cur_element)
if (new_element > cur_element)
insert(new_element)
...whether or not the work gets done on the inserted element depends
on the insertion method.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
