<<< Date Index >>>     <<< Thread Index >>>

Re: Threading bug due to a duplicated reference



* Sun Jul 24 2005 Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
> Mhh....  The loop detection currently seems to work by bailing out
> of the loop that cycles over all references in a given message.  I'm
> wondering why we don't just do this:
> 
> diff -u -r3.10 thread.c
> --- thread.c  3 Feb 2005 17:01:44 -0000       3.10
> +++ thread.c  24 Jul 2005 16:46:18 -0000
> @@ -928,7 +928,7 @@
>       if (new->duplicate_thread)
>         new = new->parent;
>       if (is_descendant (new, thread)) /* no loops! */
> -       break;
> +       continue;
>        }
> 
> I.e., go on with the next reference?

I remember I tried it once, but I don't remember why I didn't like it.
Probably yours is the best solution. My rm_dupref patch is slow.


> I'm committing that patch for now; it seems not to have any adverse
> consequences here.

I don't object to you, but I want to know your idea about this:
Well, my rm_dupref patch removes the _older_ one of duplicated refs.
For example, mine makes a tree "a->b->c->b->d" to be "a->c->b->d".
I'm unsure yours does the same (just because I don't have enough time
to read the code for now). And I'm not sure "a->b->c->d" is worse.
Which is the better? And which is the result of your patch?

I'll test your patch someday soon.
And I'd like to hear from Vincent, too.


Thanks,
-- 
tamo