Date: Fri, 28 Jun 2013 17:50:01 GMT From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Message-ID: <201306281750.r5SHo1f8069628@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> 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 > <algorithm> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306281750.r5SHo1f8069628>