From owner-freebsd-threads@FreeBSD.ORG Tue Jan 20 08:48:11 2004 Return-Path: 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 7D86516A4CE for ; Tue, 20 Jan 2004 08:48:11 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 906B143D78 for ; Tue, 20 Jan 2004 08:47:44 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (sccrmhc12) with ESMTP id <20040120164739012002ek81e>; Tue, 20 Jan 2004 16:47:40 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i0KGlc7O005173; Tue, 20 Jan 2004 11:47:38 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i0KGlbXl005172; Tue, 20 Jan 2004 11:47:37 -0500 (EST) (envelope-from rodrigc) Date: Tue, 20 Jan 2004 11:47:37 -0500 From: Craig Rodrigues To: Daniel Eischen Message-ID: <20040120164737.GA778@crodrigues.org> References: <20040120053945.GA4096@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: sem_wait() is a cancellation point in libkse? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 16:48:11 -0000 On Tue, Jan 20, 2004 at 01:02:12AM -0500, Daniel Eischen wrote: > > is a _sem_wait() which looks like it is doing > > cancellation stuff, but it doesn't > > seem to be working. > > > libc uses strong symbols for sem_wait which override > the weak symbols that libpthread is using. The sem_wait > in libc isn't a cancellation point yet. I think the > sem_foo stuff in libc should be refactored to just make > the system calls (like semop/semctl) and not know about > waiting threads. The threads libraries can wrap them > if they want to provide cancellation points and faster > userland thread switches for (process scope) thread > waits/wakeups. The thread libraries already seem to wrap sem_wait(). It is in: src/lib/libc_r/uthread/uthread_sem.c src/lib/libthr/thread/thr_sem.c src/lib/libpthread/thread/thr_sem.c sem_wait() in those files is implemented as _sem_wait(), and is a proper cancellation point. Is there anything wrong with making sem_wait() a weak symbol in libc? I tried the following patch, and it works quite nicely, i.e. tst-cancel12 in the NPTL tests now succeeds. --- sem.c.orig Tue Jan 20 11:37:35 2004 +++ sem.c Tue Jan 20 11:44:20 2004 @@ -53,6 +53,8 @@ static LIST_HEAD(, sem) named_sems = LIST_HEAD_INITIALIZER(&named_sems); static pthread_mutex_t named_sems_mtx = PTHREAD_MUTEX_INITIALIZER; +__weak_reference(_sem_wait, sem_wait); + static void sem_free(sem_t sem) { @@ -255,7 +257,7 @@ } int -sem_wait(sem_t *sem) +_sem_wait(sem_t *sem) { int retval; -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org