Ixney on the alloca. That's the entire point of not moving array allocations to the stack, because the author won't take responsibility for potential underflows and overflows. Stack is the wrong place for these bits
On Mon, Jan 17, 2022, 06:38 Eric Covener <cove...@gmail.com> 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. >
