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

[Konstantin Belousov]

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

From: Konstantin Belousov <kostikbel at gmail.com>
To: John Baldwin <jhb at freebsd.org>
Cc: bug-followup at freebsd.org, guillaume at morinfr.org, theraven at 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--