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.
Regards
Rüdiger
