From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 22 20:10:03 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4876106566C for ; Thu, 22 Apr 2010 20:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AF3EF8FC12 for ; Thu, 22 Apr 2010 20:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3MKA3js073107 for ; Thu, 22 Apr 2010 20:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3MKA3fZ073105; Thu, 22 Apr 2010 20:10:03 GMT (envelope-from gnats) Date: Thu, 22 Apr 2010 20:10:03 GMT Message-Id: <201004222010.o3MKA3fZ073105@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: John Baldwin Cc: Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:10:03 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, guillaume@morinfr.org Cc: kib@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Thu, 22 Apr 2010 16:09:34 -0400 I tracked the sigprocmask() system calls down to the operations to acquire a write lock in the runtime linker. The lock was added to fix an earlier bug with throwing exceptions in multithreaded C++ apps. The relevant commit that added the lock is this: http://svn.freebsd.org/viewvc/base?view=revision&revision=178807 Are exceptions permitted during a signal handler? If not, then in theory we would not need to invoke sigprocmask() for this particular lock perhaps? I'm not sure how easy that would be to achieve given the hooks to allow the thread library to overload the locking routines. Also, this doesn't explain the lack of sigprocmask() calls under i386. FreeBSD/i386 should be using the same locking code and thus invoking sigprocmask() for each exception as well. -- John Baldwin