kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

Kostik Belousov kostikbel at gmail.com
Fri Apr 23 17:16:13 UTC 2010


The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Kostik Belousov <kostikbel at gmail.com>
To: John Baldwin <jhb at freebsd.org>
Cc: bug-followup at freebsd.org, guillaume at morinfr.org, kan at freebsd.org,
        davidxu at freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Fri, 23 Apr 2010 16:47:40 +0300

 --z118w8IfbP8nVdqq
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote:
 > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote:
 > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote:
 > > > 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=3Drevision&revision=3D1788=
 07
 > > >
 > > > 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.
 > >=20
 > > Throwing an exception during asyncronous signal execution rises undefin=
 ed
 > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot
 > > be removed as far as we need to provide FreeBSD 4.x compatibility.
 >=20
 > Hmmm.  Why does libthr use sigprocmask() for its rtld locks then?  Is tha=
 t=20
 > just a copy-paste from libc_r that can be removed now?
 
 Hmmm^2. It seems it is there to prevent recursive entry into rtld from
 signal handler, that may reference yet unresolved symbol, e.g. libc
 syscall wrapper, from PLT. So my patch is wrong.
 
 --z118w8IfbP8nVdqq
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (FreeBSD)
 
 iEYEARECAAYFAkvRpPwACgkQC3+MBN1Mb4he1gCg18kWbb7UFBC3TGpZ1fe7vJhU
 0lUAn2Rf4j2SWLC+hdPQqJs8Qn25q+0P
 =IpCA
 -----END PGP SIGNATURE-----
 
 --z118w8IfbP8nVdqq--


More information about the freebsd-bugs mailing list