|Jonathan Lemon||Jul 2, 2002 7:53 am|
|W Gerald Hicks||Jul 2, 2002 8:08 am|
|Ian Dowse||Jul 2, 2002 8:12 am|
|Garrett Wollman||Jul 2, 2002 9:53 am|
|Julian Elischer||Jul 2, 2002 12:58 pm|
|Jonathan Lemon||Jul 2, 2002 1:34 pm|
|Julian Elischer||Jul 2, 2002 1:47 pm|
|Terry Lambert||Jul 2, 2002 3:43 pm|
|Julian Elischer||Jul 2, 2002 4:07 pm|
|Garrett Wollman||Jul 2, 2002 4:26 pm|
|Julian Elischer||Jul 2, 2002 4:35 pm|
|Julian Elischer||Jul 2, 2002 4:54 pm|
|Terry Lambert||Jul 2, 2002 5:02 pm|
|Terry Lambert||Jul 2, 2002 5:05 pm|
|Julian Elischer||Jul 2, 2002 5:50 pm|
|Bruce Evans||Jul 2, 2002 11:57 pm|
|Terry Lambert||Jul 3, 2002 10:37 am|
|Garance A Drosihn||Jul 3, 2002 10:46 am|
|Neal Fachan||Jul 3, 2002 1:46 pm||.diff|
|Julian Elischer||Jul 3, 2002 4:04 pm|
|Neal Fachan||Jul 3, 2002 5:12 pm|
|Daniel Eischen||Jul 4, 2002 6:27 am|
|Julian Elischer||Jul 4, 2002 8:36 am|
|Daniel Eischen||Jul 4, 2002 10:07 am|
|Julian Elischer||Jul 4, 2002 10:33 am|
|Daniel Eischen||Jul 4, 2002 11:29 am|
|Julian Elischer||Jul 4, 2002 11:40 am|
|Daniel Eischen||Jul 4, 2002 12:23 pm|
|Subject:||Re: additional queue macro|
|From:||Terry Lambert (tlam...@mindspring.com)|
|Date:||Jul 2, 2002 3:43:26 pm|
Garrett Wollman wrote:
<<On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon <jle...@flugsvamp.com> 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.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message