From owner-cvs-src@FreeBSD.ORG Tue Nov 2 23:27:44 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 134CE16A4CF; Tue, 2 Nov 2004 23:27:44 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE2E43D45; Tue, 2 Nov 2004 23:27:43 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) iA2NRfL6078117; Tue, 2 Nov 2004 23:27:42 GMT (envelope-from davidxu@freebsd.org) Message-ID: <418817ED.2040201@freebsd.org> Date: Wed, 03 Nov 2004 07:27:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200411011049.iA1AnY8m012136@repoman.freebsd.org> <4186960C.6090805@elischer.org> <4186C114.1000004@freebsd.org> <200411021549.27511.jhb@FreeBSD.org> In-Reply-To: <200411021549.27511.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: Julian Elischer cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_private.h thr_sig.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 23:27:44 -0000 John Baldwin wrote: >On Monday 01 November 2004 06:04 pm, David Xu wrote: > > >>Not every important, I think I have another very important history >>bug in hand, did you get my "fix famous libpthread conditional >>variable race condition" mail ? :-) >> >> > >Oooo, can I test it please? We are still having problems with mono on HEAD >here at work. I tried merging the changes in uthread_cond.c 1.32 to >libpthread but that seemed to make it worse. The problems seem to be that a >signal handler is being run when the SYNCQ sflag is set (but the thread is >not on a cv or a mutex queue), and the handler calls sem_post() which is >supposed to be signal safe. sem_post() tries to lock a mutex and then bombs >with the assertion failure. > > > You can try: http://people.freebsd.org/~davidxu/kse/thr_cond.c.diff But it was not designed to fix the problem you have seen. :-)