On Mon, Jan 9, 2017 at 10:12 AM, <wr...@apache.org> wrote: > Author: wrowe > Date: Mon Jan 9 16:12:53 2017 > New Revision: 1778004 > > PATCHES/ISSUES THAT ARE BEING WORKED > [ New entried should be added at the START of the list ] > @@ -275,6 +273,27 @@ PATCHES/ISSUES THAT ARE BEING WORKED > (& also, making the structure change with apr-util version > means it breaks binary compat across an apr-util upgrade?) > > + * Support PCRE2 (10.x) in place of PCRE (8.x). > + Submitted by: wrowe, Petr Pisar [ppisar redhat.com] > + trunk patches: > + http://svn.apache.org/r1773454 > + http://svn.apache.org/r1773741 > + http://svn.apache.org/r1773742 > + http://svn.apache.org/r1773839 > + http://svn.apache.org/r1773870 > + http://svn.apache.org/r1773882 > + wrowe notes that the current code is too inefficient, owing to the fact > + that the ovector is a required allocation and is no longer allocated on > + the stack, by design. The correct fix is an apr userdata allocation on > + the appropriate pool, which would be thread-safe, but the actual API of > + ap_regexec[_len]() offers us no pool. We cannot associate that pool with > + the ap_regex_t, because a single regex may be used by many threads in > + parallel and is not thread-safe beyond initialization. > + 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.
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?
