The following reply was made to PR kern/131597; it has been noted by GNATS.
From: John Baldwin <j...@freebsd.org> To: Konstantin Belousov <kostik...@gmail.com> Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@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 _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
