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 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).

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..

                                             /* TailQ Deletion. */
     while (!TAILQ_EMPTY(&head)) {
             n1 = TAILQ_FIRST(&head);
             TAILQ_REMOVE(&head, n1, entries);

                                           /* Faster TailQ Deletion. */
     n1 = TAILQ_FIRST(&head);
     while (n1 != NULL) {
             n2 = TAILQ_NEXT(n1, entries);
             n1 = n2;

The above taken from the man page examples.

The one that killed me (why I wrote the debug code) was:

 * Move any threads that should be suspended from the run queue
 * to the suspend queue.
TAILQ_FOREACH(from run queue) {
        if (something) {
                TAILQ_REMOVE(element from run queue)
                TAILQ_INSERT_TAIL(onto suspend queue)

Now, at first glance, the documentation suggests this should work, even
though we know it won't. but it doesn't crash.. it just terminates on the
first transfer because it reaches the end of the queue.. the suspend queue
that is..


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to