From owner-freebsd-bugs@FreeBSD.ORG Fri Jun 28 17:50:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FB3C1E7 for ; Fri, 28 Jun 2013 17:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 210111BC2 for ; Fri, 28 Jun 2013 17:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SHo1sW069632 for ; Fri, 28 Jun 2013 17:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SHo1f8069628; Fri, 28 Jun 2013 17:50:01 GMT (envelope-from gnats) Date: Fri, 28 Jun 2013 17:50:01 GMT Message-Id: <201306281750.r5SHo1f8069628@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Konstantin Belousov 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.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:50:02 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov To: John Baldwin Cc: bug-followup@freebsd.org, guillaume@morinfr.org, theraven@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 20:45:38 +0300 --8C4Pdt+UNHoLxtm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote: > On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote: > > On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: > > > Looking at this again, the patch committed in 178807 is just wrong an= d should=20 > > > be reverted. There is no state in rtld that needs to be protected vi= a a write=20 > > > lock. GCC is too lazy to use their own locking to protect shared sta= te=20 > > > between threads and wants the runtime linker to enforce this. Their= =20 > > > justification that glibc doesn't allow concurrent execution of this i= sn't a=20 > > > valid excuse. For an API like this that just walks a list and invoke= s a=20 > > > callback, if the callback manipulates shared state owned by the calle= r, the=20 > > > caller should be responsible for sychronizing access to it, not rtld! > > >=20 > > > Instead I think we should apply the patch in the original GCC bug to = our in- > > > tree GCC and to our GCC ports. This should remove the sigprocmask ca= lls and > > > not penalize other users of dl_iterate_phdr() for GCC's poor behavior. > >=20 > > In other words, we should become knowingly incompatible with the stock > > GCC and with other consumers of dl_iterate_phdr(), like libunwind ? > > E.g. libunwind ability to unwind from the signal handler relies on > > this behaviour. >=20 > Does libunwind depend on rtld single-threading to lock state shared with > other threads? If it does it should manage that itself. If GCC and/or > libunwind want to share arbitrary state between threads, or protect state > from being accessed by a signal handler, then GCC and/or libunwind should > manage that. rtld can't possibly (and shouldn't) know the rules about > how that state that is private to GCC/libunwind is managed. libunwind depends on the dl_iterate_phdr() signal-safety. >=20 > What if you had a consumer of this that wanted to access the state outside > of the callback? Then it already has to manage all the locking itself to > be safe anyway. >=20 > Put another way, requiring dl_iterate_phdr() to providing locking for con= sumers > would be equivalent to code assuming that C++'s for_each() template in > provided locking to callers. That is entirely upside-down. I think I should revive the fast sigprocmask patch. --8C4Pdt+UNHoLxtm5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzcvBAAoJEJDCuSvBvK1B9UgP/jne8523ys+JZDGUn9izYhJk LlT5LSSARhTcbREEsIevB5VQt2pbDtKsca/fCtLmaasPN5cb8XgLeyy1J3caB742 LdrXLcczv8PvSJM0D7EDTH6ktGrmAl0i9cHb8sLqHuPAD7/ZNBJRfJXWdRe4Rs3r /A78kqAdyGlJAupQ+2ocbtsIOg8F1G3L3b7iZ+gA7+txErCv5th6H3+lXalpF+8X 40FDUvpoU9roOesa9vKcQLFWcBMedLkVmTujmHrvFfMuz6zXu+0Anje5Zc0LPOSu hst4vYimFxn/VXQuU5qmGKhhz0o0jtwJzdF836aJotx2tsQWuBLWZiKSBffKQFeB D6aK0GlMlK/i6LQD+LeJbjB+k0/jxgK6ZtdetUPnPCUjeHE5IKDrm1Z0yMzMC/20 H5AQ3WdFR7Jvu11ZK6jp2aqX6BDUTTwW85c1Y/k2n5+I48vD1EDXRDO73aQkHyM8 0EU5kCPS1CRbXsf4XeGlye/YhJBNS7Hp/tdNSjhSjHckA78xLUsoKeo6LfCmFtG6 GT8oDSmyugQl6QwCNzNp9bjKJ3wSI1TZjBr8GNQI/kXZJpaJkFb6mzLLLhUbjtt/ XHrA2gaJDE9eTlOohoBO8zJ8bXe1ykK/YuduXdsAfpqKH4KckkEqUiA1ptrMV7C6 9olJnLJJMrgbMjv955u6 =/5H4 -----END PGP SIGNATURE----- --8C4Pdt+UNHoLxtm5--