Am 24.07.2019 um 01:07 schrieb William A Rowe Jr:
I'm sorry I haven't had the summertime cycles to dig into this, but am
wondering on the cusp of an httpd 2.4.40, we've learned a bunch about
possible apr pool and especially debug traps that meta
What code remains to be considered for inclusion in an apr 1.7.1?
I have added all trunk pool debug changes to 1.7.x that I found missing.
IMHO what's left changes API and would be for 1.8, see below.
What is apr 1.8 waiting for, if we think we can slightly twist things?
From the point of view of pool debugging (the only thing I looked at):
r1817892 adding apr_pool_get_tag (only indirectly a pool debug feature)
r1460182 adding apr_pool_owner_set
The parts of r1863217 that are again about apr_pool_owner_set
Do we agree you can't jump between APR_POOL_DEBUG and retain ABI to the
non-debug build?
ABI as defined "binary compatible" in the APR docs:
=== SNIP ===
We define "binary compatible" to mean that a compiled application
can be linked (possibly dynamically) against the library and continue to
function properly.
Similar to source compatibility, an application that has been
compiled against a particular version will continue to be linkable
against later versions (unless the major number changes). It is possible
that an application will not be able to successfully link against a
previous minor version.
=== SNIP ===
IMHO it should be possible to replace a normal build of the apr library
by a APR_POOL_DEBUG build of it and run unchanged apps using it, so they
should be "binary compatible". This should be easy due to the fact, that
the relevant structs, that change their behavior for debug builds,
should be opaque, so access only happens via the API and not directly on
the structs.
Furthermore apps should have no need to use different code depending on
the APR_POOL_DEBUG define. If they need to instruct the debug library
about specific decisions, like using apr_pool_join(), that code should
be usable unchanged with a non-debug apr lib (by providing the calls as
no-ops in the library. IMHO this is currently the case for trunk, 1.7.x
and 1.6.x (only HEAD, after my changes last week).
Have we eliminated the cause for APR 1.x folks to ship a release based
on APR_POOL_DEBUG?
For 1.7.x and 1.6.x (HEADS) I do think so, more eyes welcome.
What proposals are we still working to commit to apr trunk, for deep
inspection within snapshot/dev tooling builds?
None here.
Which other questions did I overlook?
Maybe a whiteboard (wiki page) for all the proposals under
consideration, or assemble these under STATUS on trunk?
Regards,
Rainer
