On Mon, Jan 17, 2022 at 02:16:32PM +0100, Ruediger Pluem wrote: > > > On 1/17/22 1:38 PM, Eric Covener wrote: > > On Mon, Jan 17, 2022 at 7:28 AM Ruediger Pluem <rpl...@apache.org> wrote: > >> > >> > >> > >> On 1/16/22 10:35 PM, William A Rowe Jr wrote: > >>> 4 day ago, you all saw this. 6 years ago, you all started using this on > >>> trunk. > >>> > >>> Don't know what I can to do help this along and honor the library > >>> author's wishes for > >>> all of us to walk away from the dead fork, and use the maintained > >>> fork. It's whatever > >>> it is, I'm out of here and removing the backport application branch, > >>> whoever 3rd upvotes > >>> this be prepared to apply this for us all, thanks. > >> > >> With regards to the de-optimization / stack usage probably stupid question: > >> Can't we use the TLS features that several compilers offer? > >> e.g. see at the end of the page at > >> https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably > >> > >> If we have no thread_local we could fall back to the current unoptimized > >> implementation? > > > > I more identified with Joe's comment, if we had an _ex version we > > could pass pools for our own usage. > > If some other heavy regex hitter third-party module finds an issue > > (like mod_security) it might degrade a little bit but they can always > > take advantage of it too. > > > > Also, what about alloca()? > > > > Trivia but I should add that in an integration between two third-party > > mods I recently ripped out apr_threadkey stuff due to a crash after > > some OS updates that nobody can explain. Fortunately the problematic > > API had been extended with userdata and it was no longer absolutely > > necessary. It was our only use of these API's so I was glad to > > simplify and just remove them and move on. > > Net, I would be hesitant to introduce something too new. > > From a quick glance apr_threadkey seems to use pthread_*specific for which I > found postings that state that it is slow compared to > the compiler implemented thread locals. OTOH __thread alike stuff does not > seem to offer any cleanup at thread exit which would > not allow us to free any resource that was created for that thread :-(. Hence > I guess providing a pool to the call remains the > only solution here.
Maybe use thread-local storage to set a pointer to an apr_pool associated with the thread, and set that only for short-lived (or otherwise appropriately scoped) threads? Cheers, Glenn
