From owner-freebsd-stable@FreeBSD.ORG  Tue May 10 06:16:00 2005
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 74D3316A4EF; Tue, 10 May 2005 06:16:00 +0000 (GMT)
Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 0E6BA43D54; Tue, 10 May 2005 06:16:00 +0000 (GMT)
	(envelope-from deischen@freebsd.org)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
	j4A6FwHV018022;	Tue, 10 May 2005 02:15:59 -0400 (EDT)
Date: Tue, 10 May 2005 02:15:58 -0400 (EDT)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Suleiman Souhlal <ssouhlal@freebsd.org>
In-Reply-To: <378E5258-A3FA-4B3E-8F3E-2E330417966C@FreeBSD.org>
Message-ID: <Pine.GSO.4.43.0505100209360.1139-100000@sea.ntplx.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net)
cc: Ewan Todd <ewan@mathcode.net>
cc: Peter Jeremy <PeterJeremy@optushome.com.au>
cc: freebsd-stable <freebsd-stable@freebsd.org>
Subject: Re: Performance issue
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Production branch of FreeBSD source code
	<freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2005 06:16:00 -0000

On Tue, 10 May 2005, Suleiman Souhlal wrote:

> Hi,
>
> On May 10, 2005, at 1:24 AM, Daniel Eischen wrote:
>
> > No, libc_r wraps execve() and a lot of other syscalls that libpthread
> > or libthr don't need to.  Take a look at libc_r/uthread/
> > uthread_execve.c
> > and you will see it sets the signal mask before exec()ing.
>
> Couldn't we do the same thing in libpthread, in the not-threaded case?
> I apologize if I'm asking stupid questions.. :)

No ;-)  We don't want to wrap functions unecessarily.  Applications
not linked to a thread library still have to use the actual syscall,
so there's no point in wrapping extra functions just to make
sigprocmask() faster when linked with libpthread.

-- 
DE