Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKQ1sVNZpsHjD+fh8oXoSGHzxWz3djSf6VP2aeVC2Uc4+GXuVg@mail.gmail.com>
References: <20170109161253.AC3363A0634@svn01-us-west.apache.org>
 <CACsi2504gn3ZSZG4E-omrtaQQq8m7pu2bG6_Z_ofZM6ttuXH9Q@mail.gmail.com> <CAKQ1sVNZpsHjD+fh8oXoSGHzxWz3djSf6VP2aeVC2Uc4+GXuVg@mail.gmail.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Thu, 12 Jan 2017 11:02:09 -0600
Message-ID: <CACsi253vyS5kuJV9fbBrUBy8Zjj+XzxduHDV_6ZAB55pO7p=dg@mail.gmail.com>
Subject: Re: svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
To: httpd <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 12 Jan 2017 17:02:20 -0000

On Thu, Jan 12, 2017 at 10:54 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 5:32 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>>>
>>> +     So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
>>> +     this as a thread safe storage buffer for the majority of cases (<10 $args)
>>> +     and we don't have a portable tls mechanism to do so.
>
> Don't we, apr_threadkey_private_*()?

Which in turn... requires the apr_pool_t * all over again, so not really;

https://apr.apache.org/docs/apr/2.0/group__apr__thread__proc.html#gacb9553b2b3165388bfc0a54b1148804a

>> Does anyone have a good suggestion on this that would be back-portable
>> and threadsafe for 2.4, before I surrender and make the trunk-only change
>> to include the worker's/thread's pool for this reusable buffer tagged with a
>> pooldata(m) in a new apr_pool_t * passed to the ap_regexec[_len] functions?
>
> Maybe having the match_data in a TLS created with a reasonable size
> (i.e. 50) on the first use?

For our purposes, I think the generic buffer of 10 ($0-$9) for most cases
is probably sufficient. But if folks like the idea (and consider that TLS may
be supporting almost 2k worker threads on an MPM like win32) perhaps
we use a quadratic reallocator, to leap from 10 to 40 to 160 or something
like that? But I would expect some 160 args to be a defective config or
malicious .htaccess exploit.

Our API isn't suited to named args, etc. At some point, a richer API might
want a bigger default. But allocating and freeing (or using a pool based
alternate allocator, with no requirement to 'free()') may be the most
efficient way to handle excessively long ovectors.