Date: Tue, 2 Jul 2002 09:05:08 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: iedowse@maths.tcd.ie, current@freebsd.org, julian@elischer.org Subject: Re: KSE status report Message-ID: <200207021405.g62E58A55302@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-current/200207021106.aa15257@salmon.maths.tcd.ie> References: <local.mail.freebsd-current/Pine.BSF.4.21.0207020054590.94626-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/200207021106.aa15257@salmon.maths.tcd.ie> you write:
>In message <Pine.BSF.4.21.0207020054590.94626-100000@InterJet.elischer.org>, 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);
}
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207021405.g62E58A55302>