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

[John Baldwin]

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

From: John Baldwin <jhb at freebsd.org>
To: Konstantin Belousov <kostikbel at gmail.com>
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 13:38:39 -0400

 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 and should 
 > > be reverted.  There is no state in rtld that needs to be protected via a write 
 > > lock.  GCC is too lazy to use their own locking to protect shared state 
 > > between threads and wants the runtime linker to enforce this.  Their 
 > > justification that glibc doesn't allow concurrent execution of this isn't a 
 > > valid excuse.  For an API like this that just walks a list and invokes a 
 > > callback, if the callback manipulates shared state owned by the caller, the 
 > > caller should be responsible for sychronizing access to it, not rtld!
 > > 
 > > 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.
 
 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.
 
 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.
 
 Put another way, requiring dl_iterate_phdr() to providing locking for consumers
 would be equivalent to code assuming that C++'s for_each() template in
 <algorithm> provided locking to callers.  That is entirely upside-down.
 
 -- 
 John Baldwin