On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> In article <local.mail.freebsd-current/[EMAIL PROTECTED]> you
>write:
> >In message <[EMAIL PROTECTED]>, Ju
> >lian Elischer writes:
> >>The big problem at the moment is that something in the
> >>source tree as a whole, and probably something that came in with KSE
> >>is stopping us from successfully compiling a working libc_r.
> >>(a bit ironic really).
> >
> >Is the new
> >
> > (elm)->field.tqe_next = (void *)-1;
> >
> >in TAILQ_REMOVE a likely candidate? That could easily tickle old
> >bugs in other code. The libc_r code does use a lot of TAILQ macros.
>
> >From casual inspection of the sources, it appears this may be the case:
>
> uthread/pthread_private.h:
> #define PTHREAD_WORKQ_REMOVE(thrd) do { \
> TAILQ_REMOVE(&_workq,thrd,qe); \
> (thrd)->flags &= ~PTHREAD_FLAGS_IN_WORKQ; \
> } while (0)
>
> uthread/uthread_kern.c (in multiple locations):
> TAILQ_FOREACH(pthread, &_workq, qe) {
> ....
> PTHREAD_WORKQ_REMOVE(pthread);
> }
This used to be safe as long as the element removed wasn't re-added to
another queue using the same link. There are other places in libc_r
where we do re-use the same link (remove from one list and add to
another), but roll our own loop in that case:
for (p = TAILQ_FIRST(&q); p != NULL; p = p_next) {
p_next = TAILQ_NEXT(p, p_qe);
...
TAILQ_REMOVE(&q, pthread, p_qe);
...
}
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
