From owner-freebsd-threads@FreeBSD.ORG  Wed Nov  3 14:21:01 2004
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id D86C916A4CE; Wed,  3 Nov 2004 14:21:01 +0000 (GMT)
Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 95A7F43D53; Wed,  3 Nov 2004 14:20:29 +0000 (GMT)
	(envelope-from mtm@identd.net)
Received: from [213.55.68.109] (HELO rogue.acs.lan)
  by telecom.net.et (CommuniGate Pro SMTP 3.4.8)
  with ESMTP id 61938183; Wed, 03 Nov 2004 17:12:24 +0300
Received: by rogue.acs.lan (Postfix, from userid 1000)
	id 0C3BEB830; Wed,  3 Nov 2004 17:19:14 +0300 (EAT)
Date: Wed, 3 Nov 2004 17:19:14 +0300
From: Mike Makonnen <mtm@identd.net>
To: John Baldwin <jhb@freebsd.org>
Message-ID: <20041103141914.GA2095@rogue.acs.lan>
References: <200411021712.11115.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200411021712.11115.jhb@FreeBSD.org>
User-Agent: Mutt/1.4.2.1i
X-Operating-System: FreeBSD/6.0-CURRENT (i386)
cc: threads@freebsd.org
Subject: Re: More mono + libpthread breakage..
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2004 14:21:02 -0000

On Tue, Nov 02, 2004 at 05:12:11PM -0500, John Baldwin wrote:
> This kicks in with mono because mono wants to call 
> 'sem_post()' (which is supposed to be signal safe) from a signal handler, but 
> sem_post() calls pthread_mutex_lock() which dies with an assertion error 
> about already being on a syncq since _cond_wait_backout() didn't happen.

Then the correct fix is for sem_post to disable signals around calls to
pthread functions. There are *no* async-signal safe pthread functions.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !