Date: Fri, 23 Apr 2010 17:16:16 GMT From: Kostik 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: <201004231716.o3NHGGHY084006@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: Kostik Belousov <kostikbel@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Cc: bug-followup@freebsd.org, guillaume@morinfr.org, kan@freebsd.org,
davidxu@freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Fri, 23 Apr 2010 17:41:11 +0300
--A47bNRIYjYQgpFVi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Apr 23, 2010 at 10:21:41AM -0400, John Baldwin wrote:
> On Friday 23 April 2010 9:47:40 am Kostik Belousov wrote:
> > 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=3D=
178807
> > > > >
> > > > > Are exceptions permitted during a signal handler? If not, then in
> > > > > theory we would not need to invoke sigprocmask() for this particu=
lar
> > > > > lock perhaps? I'm not sure how easy that would be to achieve give=
n the
> > > > > hooks to allow the thread library to overload the locking routine=
s.
> > > > > Also, this doesn't explain the lack of sigprocmask() calls under =
i386.
> > > > > FreeBSD/i386 should be using the same locking code and thus invok=
ing
> > > > > sigprocmask() for each exception as well.
> > > >=20
> > > > Throwing an exception during asyncronous signal execution rises und=
efined
> > > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and can=
not
> > > > 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=
that=20
> > > just a copy-paste from libc_r that can be removed now?
> >=20
> > 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.
>=20
> Presumably we could use a different type of lock that doesn't use
> sigprocmask() to serialize calls do dl_iterate_phdr()? I'm not sure if
> libthr would really need to overwrite the behavior of that lock or if
> a simple atomic_cmpset()-based mutex would always be fine.
During my porting of libunwind, I was told by libunwind maintainer
that they have to call dl_iterate_phdr() from signal context to
unwind, if libunwind is called from signal context.
Apparently, glibc' dl_iterate_phdr() is not signal-safe, while our is.
>
> OTOH, I'm not sure why libthr needs to use non-standard lock hooks at
> this point as they don't seem to be markedly different from the ones
> rtld uses.
libthr locks provide exclusion both for other kernel-executed threads
and signal handlers, while the rtld-default locks only protect against
signal handlers and thus libc_r-style threads.
--A47bNRIYjYQgpFVi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkvRsYYACgkQC3+MBN1Mb4jm5QCg8l0OCcuqNiutS2fpF84GQ7rW
1TcAoNwW+edk57r3KM/RaOBFybdHivHi
=JtDQ
-----END PGP SIGNATURE-----
--A47bNRIYjYQgpFVi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004231716.o3NHGGHY084006>