Le 17/01/2022 à 14:16, Ruediger Pluem a écrit :
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.
Some time ago, I played with apr_threadkey for another use case related
to mod_unique_id (see r1887244+r1887245)
It has been reverted later because getting the thread ID was not
reliable on Windows.
Discussion in BZ 65159.
I thought it could be a solution for PREC10 (see r1889287) but it wasn't.
I also looked at thread locals but AFAIK, it is not used in APR and it
was raising a potential compatibility issue with build chain.
Just my 2c.
CJ
Regards
Rüdiger
