https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #27 from Gleb Natapov <gleb at scylladb dot com> --- (In reply to Jakub Jelinek from comment #26) > (In reply to Gleb Natapov from comment #25) > > Using Torvald's rwlock would be definitely better that current state, but > > not as good as per thread lock. > > In theory there could be e.g. an option to keep using the recursive lock by > default and if e.g. dl_iterate_phdr determines it has been called already > many times, or detects contention some way, it could under that allocate the > page with the locks and switch to using that from that point on or something > similar. > Or start with rwlock and switch to array of locks, whatever. > This is interesting idea, I will try to play with it. On the surface it will be hard to make threads to agree on what method to use without some kind of synchronization which may, by itself, introduce non trivial slow down. > > I'm not a glibc developer anymore, so I'll leave it to its maintainers, just > wanted to express my fears. Your input is appreciated, especially as cooperation between two projects is required to solve the issue. > > > I think I misunderstood what you propose. My patch essentially does what you > > suggest already, it calls the function dl_iterate_phdr_parallel instead of > > dl_iterate_phdr_rd, but otherwise it is the same: it can run multiple > > callback in parallel, so we only disagree on how _parallel_ part is achieved > > internally. > > On glibc list there were some concerns about widening the interface though. > > They may prefer to use symbol versioning to change dl_iterate_phdr semantics > > (not sure if and how this can be done yet). > > Using symbol versioning to change the number of arguments of a function IMHO > is just wrong, using a different name is cleaner, and dl_iterate_phdr isn't > used these days just in glibc where I've originally added it (for the use in > the unwinder), but various other OSes, some BSDs, Solaris, ..., and not sure > if all of them use symbol versioning, especially the GNU one. > Why would new function have different number of arguments? My proposed dl_iterate_phdr_parallel has the same list of arguments, just no global lock around callback invocation. Good point about other OSes. Will bring this to glibc guys attention as an argument in favor of a new function.
