On Thu, Jan 12, 2017 at 10:54 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Thu, Jan 12, 2017 at 5:32 PM, William A Rowe Jr <wr...@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.
