kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Konstantin Belousov
kostikbel at gmail.com
Fri Jun 28 17:20:01 UTC 2013
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:17:21 +0300
--hhtCH1hro9pJkPIH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 and sh=
ould=20
> be reverted. There is no state in rtld that needs to be protected via a =
write=20
> lock. GCC is too lazy to use their own locking to protect shared state=
=20
> between threads and wants the runtime linker to enforce this. Their=20
> justification that glibc doesn't allow concurrent execution of this isn't=
a=20
> valid excuse. For an API like this that just walks a list and invokes a=
=20
> callback, if the callback manipulates shared state owned by the caller, t=
he=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 calls =
and
> not penalize other users of dl_iterate_phdr() for GCC's poor behavior.
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.
--hhtCH1hro9pJkPIH
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iQIcBAEBAgAGBQJRzcUgAAoJEJDCuSvBvK1BBuwQAIWoFrFkw9Op7RybuuAw9K5h
f49+JDpcscYrQcF8KSYWiUdV3ZcoBnubqKpT+6vWm5MQ4PwUCEv3ouKAhD/oe4n+
oJg3pQz+mFicI7s0Wr3rJFyf0vO5wcHnxDOq7XdjHIPlGqTZcnOjubdCJ42xpZkT
7004JA8B8WHitjh+9qJGQWOUDfBzUWDE3WwieqpYnKricnFhJh8/6gTg6abbZGkE
6szxxKdPMUHJ28X54HU1DV9A2TJgfjLsGIzneQtfpOp7TTIyTKfn2hFHp5eLhWB/
voH0HAegdg7ew3MaCl2fnGKb6UR0h3yShowp3KfH1LozmZNDw6C/6VSKwy55aSYY
GaVXlWEhniim7NaRgP2okdMPEz07pUt3KoIN5mQGrlvgusTUa7YXcrwCm97l72dT
EqjgffvFUPmmHP38jhgf/wkI1aQ6tY7eSqSLDM+MMBX6TnPKx4EAr3H/tc79idEx
O89zUHFJPuI7YY563O+dR0Bm09kIDPVNb3hTG09JF2KCxY3QYlje8Iu5ndKOLCi+
HvFwnTLpDEFEd22oNWdSeNUq97Rr2mAMSv5dk9A+a8mtsRbzPSeuylIKSEEKquDu
USJ2ZyISoTnZbb6Iz6SYkZRn8vOBRUfBbpPRcAJh2FkBTegl7JE7dS3tM7C26uzf
MxGTc8YbAXTWA1XFxyZR
=hwdp
-----END PGP SIGNATURE-----
--hhtCH1hro9pJkPIH--
More information about the freebsd-bugs
mailing list