From owner-freebsd-current  Tue Jul  2  7: 5:44 2002
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id DD94737B41A
	for <current@freebsd.org>; Tue,  2 Jul 2002 07:05:39 -0700 (PDT)
Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4B17A43E09
	for <current@freebsd.org>; Tue,  2 Jul 2002 07:05:39 -0700 (PDT)
	(envelope-from jlemon@flugsvamp.com)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.6/8.11.6) id g62E58A55302;
	Tue, 2 Jul 2002 09:05:08 -0500 (CDT)
	(envelope-from jlemon)
Date: Tue, 2 Jul 2002 09:05:08 -0500 (CDT)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200207021405.g62E58A55302@prism.flugsvamp.com>
To: iedowse@maths.tcd.ie, current@freebsd.org, julian@elischer.org
Subject: Re: KSE status report 
X-Newsgroups: local.mail.freebsd-current
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>
Organization: 
Cc: 
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG

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