kern/131597: [kernel] c++ exceptions very slow on FreeBSD
jhb at freebsd.org
Fri Apr 23 17:16:14 UTC 2010
The following reply was made to PR kern/131597; it has been noted by GNATS.
From: John Baldwin <jhb at freebsd.org>
To: Kostik Belousov <kostikbel at gmail.com>
Cc: bug-followup at freebsd.org,
guillaume at morinfr.org,
kan at freebsd.org,
davidxu at freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Fri, 23 Apr 2010 10:21:41 -0400
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=revision&revision=178807
> > > >
> > > > Are exceptions permitted during a signal handler? If not, then in
> > > > theory we would not need to invoke sigprocmask() for this particular
> > > > lock perhaps? I'm not sure how easy that would be to achieve given the
> > > > hooks to allow the thread library to overload the locking routines.
> > > > Also, this doesn't explain the lack of sigprocmask() calls under i386.
> > > > FreeBSD/i386 should be using the same locking code and thus invoking
> > > > sigprocmask() for each exception as well.
> > >
> > > Throwing an exception during asyncronous signal execution rises undefined
> > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot
> > > be removed as far as we need to provide FreeBSD 4.x compatibility.
> > Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is that
> > just a copy-paste from libc_r that can be removed now?
> 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.
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.
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.
More information about the freebsd-bugs